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 (index) 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/2024/07. 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.

Old manual pump in Fetonte Place Crespino, province of Rovigo [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) 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.

May 31

I'm unable to use the image I just uploaded.

Hi I don't seem to be able to use the file https://commons.wikimedia.org/wiki/File:M_F_Gervais_Holy_Roman_Empire.pdf It show up in Commons but in Wikipedia I'm not able to use it. Why? It happened for my last file and someone 'did' something... I don't know what was done but it worked. What should I do to fix it? — Preceding unsigned comment added by M F Gervais (talk • contribs) 18:45, 31 May 2024 (UTC)

@M F Gervais: It is there and it functional however due to how big and unwieldy it is as a pdf it takes a while to render, especially whern it has to develop the image cache first:

Now because PDFs are typically multipage document it can need extra formatting if you are trying to do it through standard wiki formatting. mw:help:images. PDFs should not be used if you want to display an image, please upload an image file per Com:File types — Preceding unsigned comment added by Billinghurst (talk • contribs) 07:59, 1 June 2024‎ (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. --Contributor2020^{Talk to me here!} 06:18, 17 July 2024 (UTC)

June 11

New designs for logo detection tool

Mockup for an alert when a logo is detected

Hello all! We're happy to share that we will work on logo detection in the following months and that we defined an initial approach for this.

You can read more at the project page and you can have your say in the project's talk.

We want your feedback on it, and we need your insights on how to further tune the detection tool.

Thanks for your attention! Sannita (WMF) (talk) 13:54, 11 June 2024 (UTC)

I'm rather confused. The general feed back seemed to me to amount to "logo detection isn't very useful." I was told by a couple of people when I asked informally, "Don't worry, it isn't like logo detection isn't the goal, this was just a side effect of work on something else that someone thought might be useful." And now you say that further work is proceeding on this front? What, exactly, put this on the front burner, especially given that we are constantly being reminded that dev has very limited resources for Commons? What is the problem we are trying to solve? - |Jmabel ! talk 22:25, 11 June 2024 (UTC)

@Jmabel Our impression, to be fair, was quite the opposite: that it was something that could be useful in dealing with the third-most frequent rationale for requests for deletions (the first two being copyvios and FoP, which we found it was impossible to tackle in an automated way). There was more difficulty in defining how this could be implemented, but not on its usefulness. This is why we are re-opening the feedback period, to understand how it could be implemented. Sannita (WMF) (talk) 10:36, 13 June 2024 (UTC)

@Sannita (WMF) "third-most frequent rationale for requests for deletions (the first two being copyvios" - This doesn't make sense at all. The only reason we would delete a logo is because it's a copyvio, not because its a logo. There are scores of logos which are in the public domain, either by age or by lack of creativity, while others get licensed under free licenses. I'm not sure why we should discourage people of uploading that specific content with such a warning, when those exact same rules apply to everything else. As it is, I tend to not support that implementation. And as JMabel mentioned, it's disheartening to see that resources were wasted developing such an apparently useless tool, when there are clearly established priorities (see the old wish lists, for instance). Darwin ^Ahoy! 16:16, 13 June 2024 (UTC)

@Sannita (WMF), Jmabel, and DarwIn: I'll leave others to decide on the best or most suited UI for the logo detection. As for the feature, I am supportive of this, but conditionally. Suggest this feature should be mandatory for users who do not have the appropriate user rights; I suggest users who are not admins/sysops, license reviewers, and/or autopatrolled. Users who are under these three tiers of user groups are free to upload logos and should not be slapped with this filter, since they are already aware of copyright issues and TOO considerations for logos. If possible, the feature should effectively block uses of "FileExporter" and other cross-wiki file transfer tools. And one more thing, I suggest the filter can prohibit new users (those who are not autoconfirmed) from uploading or importing logos (even photos showing logos that are non-de minimis/non-incidental). Hopefully, this will trim down at least a third or less (my guess) of deletion requests that contribute to the perennial backlogs. There are many more areas in Commons that also need attentions and resolutions, like Commons:Categories for discussion/Older (some open discussions were from before the lockdown era of 2020). JWilz12345 (Talk|Contrib's.) 08:30, 14 June 2024 (UTC)

@JWilz12345: I think the plan is for this to become a secret feature. It has no effect on the upload itself and nobody but the uploader will know about the warning. Possibly, the same effect could have been achieved by merely editing the current interface and noting "if it's a logo, follow logo guidelines". Enhancing999 (talk) 08:43, 14 June 2024 (UTC)

Just my opinion, but having a specific warning to the uploader saying the image might be a logo seems rather pointless. If not borderline condensing towards users. People generally know what they are uploading images of. The less clear thing is what license to use in any specific instance and I don't really how this deals with that. A better thing would probably just be a specific checkbox for logos that automatically adds a license and puts the image in a specific category for images that need reviewing on upload. Otherwise people are just going to just ignore the warning just like they are already ignoring guidelines by uploading the image to begin with. What we really need is better ways to review and deal with problematic images on our end though. Not try to unload that on uploaders by over complicating the UploadWizard with a bunch of warnings, extra boxes, and the like. --Adamant1 (talk) 20:52, 15 June 2024 (UTC)

@Adamant1: anything related to copyright is already complicated enough. That's perhaps a price to pay for establishing/creating a free media repository site like Commons, or more so, Wikipedia itself way back more than 20 years ago. Something that founders Wales and Sanger likely did not forseen or anticipate. (Note: just a part of my thoughts, and not a representative of my general perspective on Wikimedia movement, which I still support in the context of mandating global FoP). JWilz12345 (Talk|Contrib's.) 21:12, 15 June 2024 (UTC)

Thanks everyone for your comments! @Adamant1 about the checkbox, we thought of that option too, but ultimately decided against, because we didn't want to clutter too much the UploadWizard and make it more complicated for legitimate uploaders to upload a legitimate logo or fall into the "I'll just ignore that" kind of case. Anyway, our scope is to get to a better and more seamless way of uploading medias, but this will take more designing, prototyping, and testing, so it won't happen overnight.

To everyone, we're open to ideas for eventual moderation of logos in general, given that we don't want to unload a new bunch of work on volunteers without there being consensus. Sannita (WMF) (talk) 14:08, 20 June 2024 (UTC)

I just want to provide some context on @Sannita (WMF)'s post above ... what we're working towards here is an automatic process by which we reliably estimate the likelihood that an uploaded image will be deleted for any reason

If we had that process we'd be able to inform users that their upload is likely to be deleted (and why) during the upload process, which would be a better (and more educational) user experience than we have now. Also moderators would be able to find (and deal with) potentially problematic uploads much more easily

Our initial experiments with machine learning showed we can detect logos reliably, and they're a pretty common reason for DRs, so logo detection seemed like a promising place to start CParle (WMF) (talk) 14:36, 20 June 2024 (UTC)

There may be a misunderstanding here: being a logo is not a reason to delete. We have tens of thousands of logos legitimately on Commons. Laying aside logos that are PD because they are very old, or created by certain governments that don't claim copyrights, etc., an enormous number of logos are below the threshold of originality for copyright, especially in countries like the U.S. where that threshold is quite high. False positives -- discouraging or (worse) preventing upload of content that could legitimately be hosted on Commons -- is at least as bad, and arguably worse than false negatives, letting a "bad" file through. We can always delete a bad file; we cannot conjure a file we don't get to see. - Jmabel ! talk 19:36, 20 June 2024 (UTC)

> being a logo is not a reason to delete

Absolutely, but being a logo is a signal that the upload is more likely to get deleted. We're not proposing to prevent logo uploads, just to alert the user if what they've uploaded looks like a logo, and attempt to educate them about the copyright implications (and also flag possible logos so that patrollers can check them) CParle (WMF) (talk) 10:56, 21 June 2024 (UTC)

I'm not sure logos are actually among the things where the highest percentage get deleted. But maybe they are. Do we have any available statistics on this? - Jmabel ! talk 19:24, 21 June 2024 (UTC)

@Jmabel Sure, the most recent statistics we have are available at phab:T340546. Sannita (WMF) (talk) 16:15, 24 June 2024 (UTC)

@Sannita (WMF): I may be missing something, but I don't readily see anything there that even suggests what percentage of logos are deleted, compared to what percentage of uploads in general. Is it there and I'm missing it, or is it just not there? - Jmabel ! talk 18:22, 24 June 2024 (UTC)

@Jmabel In this comment there is a direct quote of the last part of the analysis that breaks down reasons for deletion. Sannita (WMF) (talk) 09:14, 25 June 2024 (UTC)

@Sannita (WMF): yes, I saw that. It says, in effect, "lots of logos are deleted" but with no indication of how many are kept, and how that ratio compares to other categories of files. - Jmabel ! talk 21:42, 26 June 2024 (UTC)

To use an old joke, I'm pretty sure that roughly 90% of bad uploads are by right-handed people... - Jmabel ! talk 21:43, 26 June 2024 (UTC)

I see, this could be in fact an improvement in data collecting, that I will be sure to share with the team. Sannita (WMF) (talk) 13:34, 27 June 2024 (UTC)

@Jmabel, DarwIn, JWilz12345, Adamant1, Enhancing999, Alachuckthebuck, and SCP-2000: First of all, thank you for your comments, and apologies for pinging you directly. Considering the possibility of moving forward on this topic, we have a couple of questions to ask you about it:

1. Do you think the user interface notice in the UploadWizard about detecting a potential logos should be limited only to certain classes of users (i.e. exclude explicitly autoconfirmed users and higher)?
2. Do you think a template should be created and added automatically when a logo detected by the logo detection system is uploaded to Commons with an “own work” option selected for the ease of moderation?

Let me know what do you think about it, and thanks in advance for your time and patience! Sannita (WMF) (talk) 10:04, 2 July 2024 (UTC)

@Sannita (WMF): Hi, Just a comment regarding data from phab:T340546 (P49530 Commons deleted pages most frequent edit messages, only the 20 most frequent reasons). I summed up the deletions by reason, and I get: 94,459 for copyright violations (lines 3+10+12+13+14+16+17), 76,385 for "Personal photo by non-contributors (F10)" (lines 2+5+9), and only 6,693 for logos. So logos are far down among the reason for deletion. This also reflects my personal experience as an admin. "Per COM:SPEEDY" usually means empty categories. Yann (talk) 10:41, 2 July 2024 (UTC)

@Yann Thanks for your consideration. Logos might be down among deletions, but they can also be a stepping stone towards finding a solution to other, more frequent reasons for deletion. For now we decided to focus on a limited but easily detectable part of the deletion process, and we got a tool that can provide a more than decent result at that. With the experience built on this section, we can try to tackle other reasons for deletion. Sannita (WMF) (talk) 16:48, 2 July 2024 (UTC)

@Sannita (WMF): IMO there is an even easier target for detecting copyright violations: all files with an external link as source (or anything like Google, Facebook, etc.). They should be included in a category for checking if the uploader is not an experienced user. Yann (talk) 17:05, 2 July 2024 (UTC)

What we would need is some kind of AbuseFilter that adds categories or templates after the upload process. One of the many parameters the filter can use could then be the result of the logo detection tool. Many parts for already exist the only the ability of the AbuseFilter to make edits would be needed and the new logo detection tool needs to hand over the information the AbuseFilter. GPSLeo (talk) 18:12, 2 July 2024 (UTC)

We hadn't thought of this @Yann, it's a really good idea. Added phab:T369273 CParle (WMF) (talk) 10:42, 4 July 2024 (UTC)

Not sure who the "we" is, but at Commons talk:WMF support for Commons/Upload Wizard Improvements/Logo detection I proposed 11 April of this year that what we want here is tagging, especially for logos claimed as "own work". - Jmabel ! talk 19:03, 4 July 2024 (UTC)

@Yann Hey, just to follow up on your comment about external links: we got some statistics on phab:T369273#9965672, that show that a high percentage (90%+) of medias showing an external link get deleted. They account for ~7k deletions in 2023, compared to ~8.5k for logos. Sannita (WMF) (talk) 13:33, 11 July 2024 (UTC)

June 29

Technical needs survey proposals

As somebody asked here, it would be fine to have any news about the plans for implementing the proposals selected in technical needs survey months ago. Seemingly, nothing new is publicly known after the survey finished. MGeog2022 (talk) 21:03, 29 June 2024 (UTC)

Interesting. In the meantime, the annual plan for 2024/2025 was discussed and I don't think any of this was brought up. Enhancing999 (talk) 22:59, 29 June 2024 (UTC)

This would be really disappointing, as some topics were already discussed for years --PantheraLeo1359531 😺 (talk) 11:10, 30 June 2024 (UTC)

This isn't good news. I hope they are eventually implemented, and the survey ends up being worthwhile. MGeog2022 (talk) 14:16, 3 July 2024 (UTC)

I try to annoy/bring up the topic until it's added :) --PantheraLeo1359531 😺 (talk) 17:57, 4 July 2024 (UTC)

Not sure if that would work well. For the next annual period, you could try to prepare something that can fit into the plan (with the level of generality required by the plan up to the level of detail that can bring actual change to the Commons community). Rather than requesting specific tools (which is a technical implementation question for devs), I'd attempt to phrase it in terms of functionality that should be available (users don't really care how it's done), highlighting how that fits into the general objectives.

Once that prepared (ideally before the end of 2024), you could send it to the WMF board (a Commons contributor sits there) so they can request the staff at WMF to include it in the plan. Enhancing999 (talk) 07:53, 5 July 2024 (UTC)

Maybe it would help if phabricator issues were created for the proposals.

Has the survey been brought up somewhere and/or addressed by WMF people by now? Prototyperspective (talk) 16:32, 7 July 2024 (UTC)

we should watch out for Commons:Village pump#The Community Wishlist is reopening July 15, 2024 and m:Community_Wishlist_Survey/Future_Of_The_Wishlist/Preview_of_the_New_Wishlist#July_1,_2024:_The_Community_Wishlist_is_re-opening_Jul_15,_2024._Here's_what_to_expect,_and_how_to_prepare. RZuo (talk) 21:33, 7 July 2024 (UTC)

Didn't we already have that with the result mentioned above? Maybe time to attempt a different approach. Enhancing999 (talk) 21:46, 7 July 2024 (UTC)

After a bunch of prodding, some progress was made on File upload stability (The second most voted one in the bugfix category), particularly for very large uploads. Bawolff (talk) 08:00, 12 July 2024 (UTC)

July 05

German currency files without machine-readable license

Category:Files with no license using PD-GermanGov-currency has 3,409 files which reside in Category:Files with no machine-readable license due to the fact that they use {{PD-GermanGov-currency}} ex-license which was decommissioned some years ago. Some previous discussions:

• Commons:Village_pump/Copyright/Archive/2012/07#German_currency (2012)
• Commons:Deletion requests/Template:PD-GermanGov-currency (from 2013)
• COM:CUR#Germany

Those files were nominated for deletion in 2013, but saved because it was determined that due "the response from the German government, which is now an OTRS ticket, it would appear that the hosting of these files is in line with Commons' policies." That is great, news but the files still have to have some valid license. Can some German speakers or people understanding nuances of German law help us determine if we need to create some new license templates, resurrect {{PD-GermanGov-currency}}, or delete those files? Jarekt (talk) 03:45, 5 July 2024 (UTC)

Per COM:CUR#Germany, German currency units are "Not OK except for Deutsche Mark bank notes". They can still be ok though if they're some kind of PD-old or PD-ineligible. The Deutsche Mark bank notes would probably need some new specialised license tag. The others will need to be examined one by one if they're ok for PD-old or PD-ineligible reasons, else they will need to be nominated for deletion. This is an ongoing process, just like the one concerning German stamps. I've looked at files showing German currency every now and then and either nominated them for deletion (Category:Currency related deletion requests) or replaced the PD-GermanGov-currency tag with the proper license tags. --Rosenzweig τ 07:46, 5 July 2024 (UTC)

@Rosenzweig: That is a great work you are doing in Category:German currency-related deletion requests/deleted, and a bit sad, as nobody wants to delete good files. The issue is that last time we looked at this in 2013, people were debating about 500 files in Category:PD-GermanGov-currency but 11 years latter we have 3697 files in the same category, so it seems like we gain German currency files with no license much faster than we loose them. Maybe we can start with new PD template for Deutsche Mark bank notes. What would be the rationale behind it? --Jarekt (talk) 12:56, 5 July 2024 (UTC)

I've also removed the deprecated tag from quite a few and added proper PD license tags, so it's not just deletions. The problem is that the PD-GermanGov-currency tag wasn't really properly deprecated until November 2023, so uploaders kept using it and adding files. The DM bank note conditions seem to be in VRT ticket:2012081410006029, someone would have to look at that. Though reading through Commons:Deletion requests/Template:PD-GermanGov-currency I'm a bit skeptical if they would be enough for today's Wikimedia Commons. --Rosenzweig τ 13:55, 5 July 2024 (UTC)

@Rosenzweig: , According to Krd, the ticket:2012081410006029 contains an e-mail from the German Federal Bank stating:

• They cannot answer if DM notes are PDGov ("Amtliches Werk"). This has to be decided by court if required, but they are not aware of any precedent. They do not object the use of the images if they are unmodified and used in good faith.
• They don't have any business in Euro, GDR currency or Reichmark and refer to the department of finance, or the KFW regarding GDR.

That does not seem like a good basis for PD template. So we would have to assume that all the files in Category:Files with no license using PD-GermanGov-currency are copyrighted unless we can prove otherwise. Is PD-old-70 our best option or are there some other exceptions which can be used? --Jarekt (talk) 13:30, 8 July 2024 (UTC)

I suspected it might be something like that, sadly.

We might be able to use {{PD-Germany-§134-KUG}} for some files. That is a very tricky template with several requirements:

• Can only be used for works published for the first time before 1966.
• Those works must be at least 70 years old, so as of 2024, only works before 1954 are eligible. Next year, works from 1954 will become eligible, etc.
• A personal author/artist MUST NOT be named on/in the work. Which should be usually the case with bank notes (not always with 1920s emergency money though), but coins might contain initials of the designer, which is enough for them to be named.
• A corporate entity of a specific kind (a legal entity under public law, de:Körperschaft des öffentlichen Rechts (Deutschland)) MUST be named on the work. The German Federal Bank, the German state itself or one of its subdivisions would fulfil this criterion.

That would need to be examined and decided on a case by case basis. For any works past 1965, we could not use it.

And, per Commons:Licensing, we also would have to consider US copyright (the URAA), which would mean only works which are at least 95 years old are ok. Unless we can find some provision in US law that (foreign) currency units are generally in the PD, which I'm not aware of right now. ---Rosenzweig τ 13:54, 8 July 2024 (UTC)

@Rosenzweig: , That would also mean that coins and banknotes published after 1953 can not use {{PD-old-70}}, {{PD-anon-70-EU}} or {{PD-Germany-§134-KUG}}. Those can be isolated and proposed for deletion. As for US laws, I have not seen any deletions of works in PD in home country but not in the US in last decade or so, so it is less of a priority, but it would not hurt to add {{PD-US-expired}} to currency from before 1929. Another possible approach would be to rewrite {{PD-GermanGov-currency}} as a "previously considered PD" but now no known restrictions license tag before nominating for deletion. Those files do not have known restrictions and seem no worse than other files with no known restrictions license tags. --Jarekt (talk) 16:50, 8 July 2024 (UTC)

@Jarekt: I disagree about US copyright, COM:Licensing is an official policy here at Wikimedia Commons, and files are still deleted because they're not yet in the public domain in the US. If you doubt that, just take a look at current deletion requests. So we should stick to the official policy. The German wikipedia only applies German/Austrian/Swiss copyright law, so some files could perhaps be reuploaded there on demand.

As for a "No known restrictions" license tag, are there really no restrictions? The Federal Bank more or less declares that they won't interfere (similarly here), but is that enough and free enough for a license tag? --Rosenzweig τ 17:35, 9 July 2024 (UTC)

I've looked at the category over the last few days, and it seems that a very large chunk of the files are Notgeld (emergency money) banknotes from 1923 or earlier, uploaded by a handful of users over the last five years or so (which would at least partially explain the increase in the number of files over 11 years). We will be able to keep the majority of those, either with PD-Germany-§134-KUG or because their (named) artists can be identified and died over 70 years ago. Some will have to be deleted though until they can be gradually restored over the next 25 years or so. But sorting all that out will take time. Regarding the other files (which are not Notgeld), most of the older coins and bills from the 1920s and earlier can likely be kept as well. Anything after that will probably have to be deleted and can then also be gradually restored, though very new coins and bills won't be in the PD for many many decades. --Rosenzweig τ 11:43, 14 July 2024 (UTC)

July 06

POTY (Picture of the Year) competition needs help!

POTY desperately needs new volunteers who can do the things required to run the competition. With the current state of the committee, it is likely that there will be no POTY this year, as the main member who ran scripts for the competition has burned-out from doing wikipedia tasks and isn't up for it. Others on the committee are also missing in action.

Check out the discussion here. Shawnqual (talk) 04:46, 6 July 2024 (UTC)

In the past few months there was a conversation on Commons with someone from the WMF about WMF prioritization of Wikipedias vs Commons this year. Does anyone remember who that is, could they be pinged to make them aware of this issue? I recall part of that conversation was on how Commons is not particularly focused on disseminating and sharing its content - POTY is probably the most visible initiative for Commons to share its top quality images, including outside Wikimedia, and widely engage with Wikimedia contributors across all projects (are there any stats on how many people engage with POTY, and from which wikis?). I'm sure resources for 2024 are already prioritized but visibility could help for 2025. cc @Rhododendrites who I believe was part of that conversation. - Consigned (talk) 10:11, 6 July 2024 (UTC)

This has now come up in several places. The conversation you're referring to is probably this one. There's also some background on the POTY talk page, and on Jimbo's enwp page. — Rhododendrites ^talk |  11:35, 6 July 2024 (UTC)

I think we have a problem if the commons community cannot run a photo competition without WMF's help (Or the help of people who have done it in the past. Helping out once should not imply you are signing up to help every year for the rest of your life). There are aspects of the site's operation that fall on the shoulders of WMF, but a photo competition is surely not one of them. Bawolff (talk) 07:48, 12 July 2024 (UTC)

Please someone save POTY ! This is a very important matter. The POTY contest has been completed successfully every year since 2006 and we can not let it die ! Any help is welcome. -- Giles Laurent (talk) 09:18, 8 July 2024 (UTC)

July 07

Negative boosted AI images

Should Template:Negative boosted template be added to Template:AI upscaled and Template:PD-algorithm? You could argue that most people who are using Commons would rather prefer to find non-AI images when using the search function.--Trade (talk) 21:04, 7 July 2024 (UTC)

It depends on the subject, for some subjects (and not only AI-specific ones) some AI images are the most relevant, especially when it comes to recent art genres. It's more the quality of the image that matters than how it was created. There may not be very many cases of such but I oppose it being added to PD-algorithm. I'd support it being added to items in Category:AI misgeneration. Prototyperspective (talk) 21:30, 7 July 2024 (UTC)

For actively bad images it would make sense to also include the supercategory of Category:Poor quality AI-generated images, which can look superficially useful as a thumbnail but have some fundamental error at full size. Belbury (talk) 13:22, 9 July 2024 (UTC)

(Wrt Template:AI upscaled) Overwriting images with upscaled versions (whether with AI or otherwise) is against Commons policy. Should these edits not be reverted? ReneeWrites (talk) 23:00, 7 July 2024 (UTC)

Commons is chock full of improperly overwritten files. The way the regulars talk about it here on VP, you would think something's being done, but not really. RadioKAOS / Talk to me, Billy / Transmissions 00:04, 8 July 2024 (UTC)

In fairness that's why COM:RFR was created. I don't know how effective it is in curbing destructive overwritings but it's not like there have been no attempts. The issue is that judging by what pages the template links to, the vast majority of these upscalings were done by an experienced Commons user. I assume this was a blind spot for them and they're just not aware of this policy. ReneeWrites (talk) 07:10, 8 July 2024 (UTC)

@ReneeWrites: they absolutely should be reverted.

@RadioKAOS: I certainly revert these on sight, unless it is genuinely own work by the uploader and they make that decision themselves to overwrite. - Jmabel ! talk 02:41, 8 July 2024 (UTC)

The template is to flag that an image may contain speculative AI-hallucinated content, not that the Commons image has been overwritten. Most AI-upscaled images are uploaded as separate files (sometimes, frustratingly, instead of the original, where a user pulling historical photos from old newspapers thinks they look better with the AI treatment). Belbury (talk) 10:57, 8 July 2024 (UTC)

"You could argue that most people who are using Commons would rather prefer to find non-AI images" We can argue lots of things of course, but is this actually the case ... I'd avoid this kind of reasoning, we do not know why people look for the things they look for. Better to make actual judgements on proper arguments. The negative boosted template is a pretty aggressive downrank (similar to that which deletions get) which I would not advise using for anything but literal trash, and thus I would not advise in this case. If it should be downranked with a different value is something that I'd be open to (based on arguments), but we would have to define and add extra levels of derank templates for that to work. —TheDJ (talk • contribs) 14:33, 9 July 2024 (UTC)

Some Commons users won't mind being served AI images. A number of Wikipedia projects seem very relaxed about using AI-upscaled or entirely AI-generated images for biography articles, apparently preferring them to lower-quality historical images. If I myself was looking for a drawing or an icon I wouldn't dismiss an AI-generated image out of hand.

But there is definitely an issue where a user may find it hard to distinguish real photographs from artificial ones, when searching. Right now, a search for "astronaut" is okay for the early results being a mix of photos and cartoony artwork - the photos are all (I think!) genuine, the cartoons are either AI or hand-drawn. There's nothing misleading there. But a search for "london steam train" has a completely fake AI image in the first few results, which only becomes apparent if you click through or hover to read the filenames. Belbury (talk) 13:01, 10 July 2024 (UTC)

Good points, in your second link the problem is mitigated to some extent by the good file naming so when hovering over the AI image one sees a tooltip over it and the URL in the bottom left with "AI-generated" in the title (even when at VP/Proposals many have opposed a policy guideline for descriptive file naming). I think the best approach would be to have a tag in a corner of the thumbnail image that clarifies the image is entirely/largely made using some AI tool, and so even when glancing over the search results. Prototyperspective (talk) 20:09, 10 July 2024 (UTC)

July 08

License template request: AGPLv3 only

Could someone create the license template Template:AGPLv3 only? We currently only have Template:AGPL, and that's not acceptable for files that don't use the "or any later version" clause.

We already have Template:GPLv3 only, which makes this distinguishment for Template:GPLv3.

I'd create the template myself, as I've recently uploaded an AGPLv3-only file, but I have zero experience with template creation and wouldn't even know where to start.

It also occurred to me that there might be some files incorrectly marked as AGPL, since the correct license tag doesn't exist and apparently never has, so the logical step for the lazy is to just use the AGPL template and be done with the upload (which I'll also do, though I'll change the license to the correct one once someone creates the template).

Dunno if this helps, but the Wikidata ID for AGPLv3 (ie. AGPLv3 only) is GNU Affero General Public License, version 3.0 (Q27017232) and AGPLv3 (containing the "any later version" clause) is GNU Affero General Public License, version 3.0 or later (Q27020062). --Veikk0.ma (talk) 01:25, 8 July 2024 (UTC)

I've created Template:AGPLv3 only, but I'm waiting for a translation admin to mark Template:AGPLv3 only/i18n for translation. I might have done something wrong with the i18n stuff so if a more experienced user/translation admin can check that would be wonderful. —Matrix(!) {user - talk? - _uselesscontributions} 10:25, 9 July 2024 (UTC)

@Veikk0.ma:  Done, see Template:AGPLv3 only, you can use/translate it now. —Matrix(!) {user - talk? - _uselesscontributions} 17:11, 11 July 2024 (UTC)

Many thanks! --Veikk0.ma (talk) 00:00, 12 July 2024 (UTC)

ISO 24138 - International Standard Content Code - ISCC

What is the position of Commons on the International Standard Content Code (ISCC - ISO 24138) https://iscc.io/ ?

As neither the english-languaae Wikipedia nor the german-language Wikipedia have an article on ISCC, don't mention it in the ISCC-disambiguation page and do not even mention it anywhere, I fear, that there is no postion about ISCC at Commons? @Legoktm: --C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:30, 8 July 2024 (UTC)

I wasn't aware of ISCC up until now. Was there a specific reason you pinged me? Legoktm (talk) 02:20, 9 July 2024 (UTC)

Yes, someone tagged you about ISCC on Mastodon a few days ago (in connection with an annocement about ISCC and the expressed hope that Commons would use it). C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 02:33, 10 July 2024 (UTC)

How about adding a SDC prop for ISCC? --C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:31, 8 July 2024 (UTC)

It seems like this is a fancy version of perceptual hashing. (More specifically, it is a combination of 4 hashes - a (similarity) hash of the metadata, a perceptual hash of content, a semantic hash of content, and a cryptographic hash of content). According to one of their press releases it will help track the profiliation of AI fakes, but i have no idea how that would work and sounds like trendy buzz word BS. I guess it might be useful to include it on commons if it becomes a widely used standard (The same way SHA1 hashes of images are useful) and it has some applications to finding similar images. I guess the intention is to easily compare the content on different repositories to find both duplicates and near-duplicate media. I imagine ideally such hashes would be generated automatically and not simply a prop in SDC that users fill out since its a hash and not subjective. Bawolff (talk) 07:34, 12 July 2024 (UTC)

Potentially confusing page naming

We have both Commons:Primeiros passos and Commons:First steps/pt with the level-1 heading "Primeiros passos". This seems potentially very confusing. Any thoughts? - Jmabel ! talk 18:26, 8 July 2024 (UTC)

Easy, like it or not, English is the default language for the project. It's a pragmatic decision, and obviously assists search. Other languages can be echoed by creating a companion page in Wikidata. Broichmore (talk) 19:10, 8 July 2024 (UTC)

@Broichmore: one of us is missing the other's point; I'm not sure which. For Portuguese-language users, this results in two rather different pages that effectively have the same title. Are you saying that's not at all a problem, or not one worth fixing, or something else? And I can't see what Wikidata has to do with the matter at all. - Jmabel ! talk 00:09, 9 July 2024 (UTC)

Yes, I missed the point. The two pages should, could be, amalgamated TBH. Broichmore (talk) 10:00, 9 July 2024 (UTC)

On closer look, this seems to be a problem also for Commons:First_steps/de and Commons:Erste Schritte and around 20-30 more languages (everything in {{Header|Lang-FS}}) as a lot of these translations were created pre-2010 before we had mw:Extension:Translate. Ideally, they should be redirected to the correct version (Commons:First steps/xx) (the versions are so different there's little point merging). —Matrix(!) {user - talk? - _uselesscontributions} 10:34, 9 July 2024 (UTC)

But that seems to raise the question of whether Commons:Primeiros passos, Commons:Erste Schritte, etc. have some content worth preserving.

I'd suggest that some people whose native language is other than English might want to look into this for their respective native language. - Jmabel ! talk 16:54, 9 July 2024 (UTC)

There is also the question whether these pages should be translations from an original in English or edited freely by the community. Should the "content worth preserving" be translated and added to the English version or added to the translated page in pt/de/…? What about things that are especially relevant for many speakers of the other language, such as references to local law or clarifications generally not needed for the Anglosphere? –LPfi (talk) 19:51, 13 July 2024 (UTC)

July 10

Does Pywikibot still work?

Yesterday I have uploaded File:Brückner Vielflache Fig. 42.jpg using Pywikibot. After one image I have stopped the script, to fix a detail in the description. But since then I was not able to upload the other images. The main error messages are An error occurred for uri https://commons.wikimedia.org/w/api.php and The write operation timed out.

all error messages

Uploading file to commons:commons... Sleeping for 7.3 seconds, 2024-07-10 17:23:06 ERROR: An error occurred for uri https://commons.wikimedia.org/w/api.php ERROR: Traceback (most recent call last): File "/home/PATH/env/lib/python3.12/site-packages/pywikibot/data/api/_requests.py", line 684, in _http_request response = http.request(self.site, uri=uri, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/PATH/env/lib/python3.12/site-packages/pywikibot/comms/http.py", line 283, in request r = fetch(baseuri, headers=headers, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/PATH/env/lib/python3.12/site-packages/pywikibot/comms/http.py", line 457, in fetch callback(response) File "/home/PATH/env/lib/python3.12/site-packages/pywikibot/comms/http.py", line 343, in error_handling_callback raise response from None File "/home/PATH/env/lib/python3.12/site-packages/pywikibot/comms/http.py", line 448, in fetch response = session.request(method, uri, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/PATH/env/lib/python3.12/site-packages/requests/sessions.py", line 589, in request resp = self.send(prep, **send_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/PATH/env/lib/python3.12/site-packages/requests/sessions.py", line 703, in send r = adapter.send(request, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/PATH/env/lib/python3.12/site-packages/requests/adapters.py", line 501, in send raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', TimeoutError('The write operation timed out')) WARNING: Waiting 5.0 seconds before retrying.

Was something changed yesterday? My script is the same that has worked for the one uploaded file. --Watchduck (quack) 15:42, 10 July 2024 (UTC)

I have succesfully uploaded photo today. If you dont already do try to use asynchronous=True for upload. If that doesn't help try to set socket_timeout for wikibot. ie.

pywikibot.config.socket_timeout = 120
site = pywikibot.Site("commons", "commons")  # for Wikimedia Commons
site.login()
image_file_path='/tmp/example.jpg'
commons_file_name = "File:example.jpg"
file_page = pywikibot.FilePage(site, commons_file_name)
if file_page.exists():
        print(f"The file {commons_file_name} exists.")
        exit()
file_page.text = wikitext
summary = "Uploading example.jpg"
file_page.upload(image_file_path, comment=comment,asynchronous=True)

--Zache (talk) 16:48, 10 July 2024 (UTC)

pywikibot.config.socket_timeout = 120 worked. Thanks. --Watchduck (quack) 17:02, 10 July 2024 (UTC)

July 12

"campaign323@ISA"

Does anyone know the significance of "campaign323@ISA"? I am seeing a lot of bad "depicts" with that as an edit summary. - Jmabel ! talk 01:59, 12 July 2024 (UTC)

STL files visualization

Hi all, for the past few weeks, I haven't been able to view STL files that are uploaded to Commons (for example these: Category:STL files from Museo di storia naturale dell'Università di Pisa). The thumbnail shows up fine, but when I click on the eye icon, I get an error message, that reads "Sorry, the file Undefined cannot be displayed since it is not present on the current page. Go to the corresponding file page". The last sentence is a link, but leads to a non-existent "Undefined" page. Up until a few weeks ago, a window would open with the 3D image, which I could rotate and view. Any idea what's going on? Thanks a lot! --Marta Arosio (WMIT) (talk) 12:20, 12 July 2024 (UTC)

Yes, unfortunately, the 3D functionality on Commons is not very well curated. A requested feature to be able to upload textured meshes is also stuck for years now. We as community hope that these issues will be adressed, but until now, nothing huge happened :( --PantheraLeo1359531 😺 (talk) 14:05, 12 July 2024 (UTC)

Created the issue a few weeks ago here

Tracked in Phabricator
Task T368301

Prototyperspective (talk) 14:46, 12 July 2024 (UTC)

Thanks @Prototyperspective: ; I am noting now that the 3d rotation is indeed still accessible, if you click on the miniature within a Wikipedia article. The page that opens then presents the image that can be rotated. This does not work clicking on the same miniature on Wikidata. For an example, see this file File:Panthera pardus 3d scan Natural History Museum University of Pisa C 1389.stl on this article w:Leopard. --Marta Arosio (WMIT) (talk) 09:34, 16 July 2024 (UTC)

Thanks, didn't know STL files still work on Wikipedia. I'll add this info to the code issue. The file does open and rotate on Wikidata on my side so maybe that got fixed since your comment or there is some issue in your browser. Prototyperspective (talk) 11:12, 16 July 2024 (UTC)

Template for Most Valued Image Closure on COM:VIC

Hello everyone. Often, I have taken 15-20 minutes to close a single Most Valued Image Closure on COM:VIC since it doesn't have an existing template and we have to keep our eyes wide open as scope for mistakes are much wide open when we approach this type of closure. Hence, for a long period of time, I am trying to create a template which could do the work so. However, given I have not much expertise in template building, I couldn't be able to do so. However, what I think is I have created a very, very raw template which still cannot do things as expected, but is a start. If anybody can help, it will save much time for our fellow volunteers hoping to close MVRs. (feel free to express your criticisms about the template, I admit it is the trashiest draft ever made. It would be much highly appreciated if you can also create an entirely new template.)
I request you to refer to COM:VICL on what are the current conditions on closing a Most Valued Image Closure.
Thanks in advance, Contributor2020^{Talk to me here!} 16:10, 12 July 2024 (UTC)

July 13

Deletion nominations using only no-fop as reason

Example: Porta Susa old station building 2016 4 This is the old station of 1856, not the New one. So some explanation as to why this building is protected is needed. The same for the nummers 1 to 3. Smiley.toerist (talk) 07:23, 13 July 2024 (UTC)

Courtesy links:

• File:Porta Susa old station building 2016 4.jpg, and
• Commons:Deletion requests/File:Porta Susa old station building 2016 4.jpg.

Commander Keane (talk) 10:19, 13 July 2024 (UTC)

From the perspective of the deletion nominator, Template:NoFoP-Italy says This image features an architectural or artistic work, photographed from a public space in Italy, which is true for the deleted picture... Maybe it should make it clearer with something like This image features a recent architectural or artistic work, photographed from a public space in Italy. Maybe User:Mazbel can shed some light on the error. Commander Keane (talk) 10:35, 13 July 2024 (UTC)

@Commander Keane@Smiley.toerist anything in public domain is PD. Free to be licensed under commercial CC licensing. Italy is a Berne signatory, and current Berne Convention rules prohibit copyright renewals (reflected in the 1940s copyright law of Italy that is the law in force today), so it is unlikely the architect's grandchildren can claim copyright over a work that has fallen into PD. Those DRs must be closed as keep. JWilz12345 (Talk|Contrib's.) 10:45, 13 July 2024 (UTC)

@Commander Keane: Regarding what I was tagged, when it came to nominating it to DR, I relied on the template description as mentioned above, being a work of architecture. Thus, the error can be attributed to the unclear text you quoted at the beginning. On the other hand, (correct me if I misinterpreted), did the second quote correspond to a suggestion to change the text of the template? Finally, as JWilz12345 makes explicit, grandchildren are unlikely to claim copyright to a work that has already fallen into the category of PD.--Mazbel (Talk) 03:11, 14 July 2024 (UTC)

@Mazbel was that template tagged at those four images? If so, that tag should be removed from the said images. You may want to replace it with {{PD-old-architecture}} (only for PD buildings in no-FoP countries). JWilz12345 (Talk|Contrib's.) 03:14, 14 July 2024 (UTC)

@Mazbel, the second quote suggested adding "a recent" to the template description, possibly linking to PD-old may be good. Commander Keane (talk) 03:17, 14 July 2024 (UTC)

@JWilz12345: Hmm if you refer directly to the image file, the {{NoFoP-Italy}} template is not present, only in the DR. However, it is good to add the {{PD-old-architecture}} template to those photos, to avoid future mistakes. @Commander Keane: Yes, I think it would be good to open some discussion on that. Maybe with that small change, it would avoid inconveniences like the above. Greetings to both of you! --Mazbel (Talk) 03:27, 14 July 2024 (UTC)

@Mazbel When you make such DRs, could you also please add the relevant category? Otherwise nobody can check your claims and the images get deleted after a week unless somebody casually notice them. Friniate (talk) 16:36, 14 July 2024 (UTC)

There are stil two delete nominations active. File:Porta Susa old station building 2016 1.jpg and File:Porta Susa old station building 2016 3.jpg.Smiley.toerist (talk) 16:04, 16 July 2024 (UTC)

Potential copyright problem -- best course of action?

(Discussion moved to right place) Any guidance appreciated. --Rlandmann (talk) 10:13, 13 July 2024 (UTC)

Good luck with it, but this is the page you should be on, with this. Broichmore (talk) 19:47, 13 July 2024 (UTC)

Many thanks; I'll move it. --Rlandmann (talk) 22:52, 13 July 2024 (UTC)

File:Baron Moncheur, F.R. Coudert, W.D. Robbins LCCN2014719398.jpg

At File:Baron Moncheur, F.R. Coudert, W.D. Robbins LCCN2014719398.jpg I get the hidden category when I use {{taken on|August 21, 1917}} but I do not get it when I switch to {{taken on|1917-08-21|location=United States}}. I need the country because there are other countries in the August 21, 1917 category. How do I make the category hidden, like the others? --RAN (talk) 14:24, 13 July 2024 (UTC)

You can create the category page with the same content as the category for the day before. --Geohakkeri (talk) 15:51, 13 July 2024 (UTC)

July 14

Category:2024 shooting at a Donald Trump rally

Any protests if i move this to "2024 assassination attempt of Donald Trump"?--Trade (talk) 02:16, 14 July 2024 (UTC)

Why is it necessary to specify the year? Were there previous assassination attempts on President Trump? Elizium23 (talk) 02:24, 14 July 2024 (UTC)

It's not necessary at all Trade (talk) 02:29, 14 July 2024 (UTC)

Perhaps it is too soon, and things are changing rapidly enough. The category name, as it is, isn't inaccurate, so I'm in no hurry to change it. There is still significant variance in the article names in different languages, and there is certainly a large discussion on enwiki to change the name of the main article, as well. Elizium23 (talk) 02:33, 14 July 2024 (UTC)

It could be useful to see at one glance when an assassination attempt took place --PantheraLeo1359531 😺 (talk) 10:24, 14 July 2024 (UTC)

It is now at Category:Attempted assassination of Donald Trump in case anyone was interested. Commander Keane (talk) 01:41, 15 July 2024 (UTC)

• Why was the redirect deleted, it appeared useful. --RAN (talk) 03:32, 15 July 2024 (UTC)

  Would support --PantheraLeo1359531 😺 (talk) 07:24, 15 July 2024 (UTC)

New version of the upload wizard doesn't seem to collect enough licencing information

Tracked in Phabricator
Task T370049

I took a CC-BY-SA photo from Commons File:Craignish Rainbow.jpg and cropped it to focus on the landscape rather than the sky which I uploaded as File:Craignish_Landscape,_2017.jpg. OK, there is no problem for me to do this given the original work was CC-BY-SA. But when I was in the licensing screen in the upload wizard, I was able to tick a box to say that I was uploading a work that contained the work of others and that it was a licence accepted on Commons, but nowhere on that screen did I get to say what/where the source was. Surely for both the purposes of licence checking and attribution, I needed to identify the original image. Previously there was a box called (I think) "source" where I would previously have written like "Crop of File:Craignish Rainbow.jpg" enabling the licence to be checked and attributing the original creator of the image. When I came to the next screen (where you name it, describe it, categorise it, etc), I added the "Crop of ..." into the "Other information" box. OK, I think I've done my best to do the right thing by the original creator of the work by doing this, but I feel that most people won't think about doing that without being prompting and, as it relates to licensing, I should it should form part of the previous screen. I think after ticking the box saying it contains the work of others, there should be question(s) to identify what works of others are involved and their licencing. Or am I missing something? Kerry Raymond (talk) 02:31, 14 July 2024 (UTC)

Pinging @Sannita (WMF). - Jmabel ! talk 05:20, 14 July 2024 (UTC)

@Kerry Raymond Thanks for the thorough report. I'll open a Phab ticket about it, and see that we address it at the next meeting available. Sannita (WMF) (talk) 08:55, 15 July 2024 (UTC)

Category:Charles Darwin

At Category:Charles Darwin we have a family tree. People with Commons Categories get a blue link. But, Josiah Wedgwood does not get a blue link even though he has a category. When I click on the Wikidata link to see why, it takes me to the Russian language version for Josiah Wedgwood at Wikidata. Can anyone figure out why one entry is doing this incorrectly but the others work fine. The template for the family tree was imported from the Russian Wikipedia a few years ago. --RAN (talk) 16:49, 14 July 2024 (UTC)

The Russian thing was an easy fix. --Geohakkeri (talk) 17:03, 14 July 2024 (UTC)

• What was the secret? And why still no blue link to the category? --RAN (talk) 03:31, 15 July 2024 (UTC)

Commons talk:Media knowledge beyond Wikipedia

I've added a new response at the bottom of this talk page, maybe it can be worth reading and/or commenting on it if you want. MGeog2022 (talk) 17:50, 14 July 2024 (UTC)

July 15

Photo challenge May results

Pets: Entries • Votes • Scores

Rank	1	2	3
image
Title	Australian Shepherd Dog	Hachi and Boy	Cat enjoying the sun between daisies
Author	Ermell	HachiBoy	Lusi Lindwurm
Score	27	15	13

Waves: Entries • Votes • Scores

Rank	1	2	3
image
Title	This was shot in Kakinada Beach, shows struggle of fishermen in middle of sea	A wave painted with a white neon lamp in a flashlight, city beach in Płock, Poland.	Port Saint-Michel in Batz-sur-Mer
Author	Zahed.zk	Lightpainterplock	Ibex73
Score	28	19	11

Congratulations to Ermell, HachiBoy, Lusi Lindwurm, Zahed.zk, Lightpainterplock and Ibex73. -- Jarekt (talk) 01:19, 15 July 2024 (UTC)

Works of art of men smoking (activity)

I've just noticed an item, moved from Category:Smoking men in art to Category:Works of art of men smoking (activity). That just rolls of the tongue, its so intuitive (sic). I thought that brevity was supposed to be the way to go. That what was important, was, that titles be consistent, brief getting to the point quickly, even be elegant. Works of art of men smoking (activity) is the exact opposite of that.

As an aside, what was wrong with just Smoking cigarettes, which is how a commercial endeavour would probably do it. Only humans, of all the animals, are stupid enough to smoke.

Another cat recently moved, from Category:Walking men]] to Category:Men walking. Somehow, I got used to using titles that led with the verb, now, not the case. It has to be the noun.

Why can't there be both, is that such a deal breaker? Broichmore (talk) 16:16, 15 July 2024 (UTC)

See also Commons:Categories for discussion/2024/07/Category:Works of art of women smoking (activity).

 Agree with Broichmore that category names should be as short as possible. Therefor I prefer Category:Smoking men in art above Category:Works of art of men smoking (activity). But sometimes that conflicts with the Universality Principle. So then we should have a discussion about what prevails: short category names or the Universality principle (or any other principle on Commons)? JopkeB (talk) 07:56, 16 July 2024 (UTC)

I likewise agree that brevity is preferable, but not at the expense of clarity. We need to maximize accessibility for all users, not just those of us who have been around long enough to 'get used to' idiosyncrasies. As for changing this category:

1. It seems already agreed to return to 'in art' from 'works of art' in the above linked CfD.
2. Discussion over whether or not (activity) is a useful dab is at Commons:Categories for discussion/2024/07/Category:Smoking (activity), so that dab may also be done away with shortly.

Josh (talk) 13:11, 16 July 2024 (UTC)

What are free media resources for illustrations?

I think illustrations (recent examples) are some of the most useful, most educational, and most needed kind of media on Wikimedia Commons.

What are some good sources for them? Please see Commons:Free media resources/Illustrations which I just created but as of now only has one item.

Moreover, could there be another list for free media resources for datagraphics like charts? Currently, I don't know of many items for such a list either except for Our World in Data. Prototyperspective (talk) 13:19, 15 July 2024 (UTC)

July 16

Psilota decessa -> Psilota decessum

Hopefully a super-simple issue, there's a creature - a fly species which the name spelling changed slightly from "Psilota decessa" to "Psilota decessum"

It has two wikidata files now, i think that's what's desirable on there even for such minor name differences - here the last letters of the species name only changes due to some taxonomy mumbo-jumbo [explained on wikispecies]. https://www.wikidata.org/wiki/Q21325248 https://www.wikidata.org/wiki/Q14518044

I'm unfamiliar with wikimedia commons. I think that i've changed it to revised Category:Psilota decessum, but where i think it's calling to "Wikidata Infobox" that's still reflecting the (older, wrong) Psilota decessa from it's wrong wikidata. I've tried changing some links that wikidata end, but what am i missing? In other words, I want that "Wikidata Infobox" to instead be reflecting Q14518044 Sjl197 (talk) 01:07, 16 July 2024 (UTC)

Heh-heh, "super-simple" heh-heh, famous last words!

Yes, that is indeed arcane mumbo-jumbo about a Latin language declension issue. If I'm understanding this correctly, and this is really a case of "old/deprecated/incorrect" spelling, then I'm not sure we can justify separate Wikidata items. I think we should go over there and propose a merger. It is, however, notable that they carry different taxon IDs at various sites, but hopefully those can be kept in a unified/merged item with appropriate documentation.

If we can't merge them on Wikidata then that may complicate the representation on Commons and other projects. I'd prefer a simple and straightforward process instead. Elizium23 (talk) 01:24, 16 July 2024 (UTC)

I had Latin as subject in school, and to me, it seems like the Psilota decessa looks better, as the second word complies the concord in "Kasus", "Numerus" and "Genus" --PantheraLeo1359531 😺 (talk) 11:08, 16 July 2024 (UTC)

I simply assumed that for any specialized field, be it bio-taxonomy or pharmaceuticals, the Latin language has progressed and specialized beyond its actual linguistic roots, and clearly in this case, they're applying extremely arcane and specific rules to it. (The dictionary link indeed went to wikt:decessuum, which indicates that all derivatives use macrons as well, so there are liberties taken.) Elizium23 (talk) 16:31, 16 July 2024 (UTC)

and yes, when i started looking into the issue a couple of days ago i had the view that "Psilota decessa" seemed a tolerable formation, i.e. per gender agreement between two parts, the genus as feminine and adjectival species name, but yes, biological latin is indeed a derivative, with many extra issues as due any specialist field, even worse this has several hundreds of years of baggage about all that! Sjl197 (talk) 05:07, 17 July 2024 (UTC)

@Sjl197: The correct name is P. decessa, not P. decessum. When Hutton described it in 1901, he assigned it to the genus Melanostoma. Melanostoma is neuter, so he used the neuter form of the adjective, decessum. When the species was later moved to the genus Psilota, it changed from neuter to feminine (because Psilota is feminine), and the adjective changed with it, to decessa. The invalid form Psilota decessum is a solecism used only by those who do not understand Latin. (The comment on Wikispecies, that decessum is a noun, is wrong: there is no noun with the nominative form decessum. The link there points instead to the form decessuum with two U's, which is the genitive plural form of the noun decessus. All of the changes to P. decessum should be reverted back to P. decessa. Crawdad Blues (talk) 21:24, 16 July 2024 (UTC)

Editing to add that ICZN 31.2.2, cited on the Wikispecies page, is irrelevant here, because there is no noun with the nominative form decessum that Hutton could have intended. The word must therefore be treated as an adjective. You assert in your rename requests that this word is now treated as an "invariant noun" (on whose authority? no source is cited), but if that were the case, it would be decessus, not decessum. I fear you have expended a lot of effort on a misunderstanding. Crawdad Blues (talk) 22:20, 16 July 2024 (UTC)

I think Crawdad Blues is entirely correct here. - Jmabel ! talk 04:26, 17 July 2024 (UTC)

Was @Sjl197 involved in GBIF or iNaturalist changes in some way? Because those sites are both convinced about the decessa -> decessum deprecation. GBIF deleted the taxon in 2016. iNaturalist site bears the same GBIF citation mentioned here. opentreeoflife.org doesn't seem to differentiate them too much. So other than applying a knowledge of Latin declensions (which seems sort like Original Research to me?) does anyone have a reliable secondary source, other than this GBIF thing we're looking at, which clearly documents that decessa is the preferred and modern name? Elizium23 (talk) 04:40, 17 July 2024 (UTC)

@Crawdad Blues: etc. Well, going back to start, my "super-simple" were apparently indeed famous last words! There's a lot said above Crawdad Blues to indicate good knowledge of "Biological latin" so i'm grateful, but many bold statements which i'm wary about. We agree on the early formation by Hutton, where his Melanostoma decessum does seem perfectly formed as a neuter adjective. That's how I was viewing it a couple of days ago, if so, then recombined with the feminine Psilota would indeed 'simply' give Psilota decessa. To briefly answer @Elizium23, then indeed i'm on iNat also, so involved with changes there. That was my starting point to the whole issue. To my view, there is nothing on iNat that is "convinced about the "decessa -> decessum deprecation", it's got both versions active, which cannot be, i'd only setup so decessum would be preferred, but thats on hold [1]. I wasn't involved in GBIF (where decessa was deleted in 2016), but from other things they do, then i'd say that deletion is not necessarily linked to any informed change, but may be a change in usage on one of their sources, hence I direct you to Systema Dipterorium [2] which GBIF largely takes as the authoritative catalog for that group, and their view feeds into several databases. Point is, there's a bunch of resources that seems to have shifted from "decessa" to "decessum", several done long before i've tried unifying iNaturalist to a single active name, then various Wikis - leading to this discussion.

On the actual nomenclature issue, i'm now seeing that i've misstepped on some editing of the Wikispecies. I had edited the Note: Under ICZN" etc, but i had not created that. It's the only justification i found anywhere about why "Psilota decessum" could be the form to use. Please see under the "Talk" page (same Wikispecies), for a response now from the user who created that text, which i'd modified. He also merged "Psilota decessa" -> "decessum" (also on wikispecies) back in 10 January 2023‎. I'll admit i was wrong about my edit to specify the genitive "decessuum (with two U's). He also points out same. I had misread the genitive in the wiktionary table. Before my very recent edit to that (in hindsight wrong) genitive, his previous wiktionary link was pointing instead to the accursative singular case which DOES read "decessum", i.e., spelt the same way as neuter adjective [https://en.wiktionary.org/wiki/decessum#Latin]. Above is said "(The comment on Wikispecies, that decessum is a noun, is wrong:". I don't agree it says that - it reads "the epithet "decessum" is treated as a noun". Unless you or someone well versed in linguistics can explain why not, to me any case of a noun such as "decessum" is still a noun. As for "You assert in your rename requests that this word is now treated as an "invariant noun (on whose authority? no source is cited)", the Wikispecies already states "Under ICZN Art. 31.2.2". So it's under the authority of that article of the ICZN, i felt that was clear. Here's what that article says: "31.2.2. Where the author of a species-group name did not indicate whether he or she regarded it as a noun or as an adjective, and where it may be regarded as either and the evidence of usage is not decisive, it is to be treated as a noun in apposition to the name of its genus (the original spelling is to be retained, with gender ending unchanged." Now, with that in hand (and admitting i was wrong on the genitive), the crux really is whether "decessum" in the accursative singular would fit with "31.2.2." or not. I'd wrongly switched the Wikispecies wording to specify the genitive plural as i felt other things said by ICZN allow for nouns of species epithets to be in nominative (as said repeatedly above by Crawdad Blues but also allows them as genitives. As the noun spelling is neither nominative nor genitive, i now feel things get murky. Firstly, does the text in "31.2.2" exclude nouns in accursative singular? I'd say that text is ambiguous about cases. Secondly, if for argument sake we accept decessum as a noun, and its accursative case as acceptable, then follow adoption that way, i can't agree when Crawdad Blues said "that would be decessus, not decessum". I'd say "31.2.2" clearly reads that "the original spelling is to be retained, with gender ending unchanged" ergo decessum. Ok, all that said, back to IF decessum were the genitive spelling, i'd hold strong on maintaining it can be treated as a noun and case closed. But now i've realised it's only in accurative singular, then we're into some arcane arguments about interpretation of ICZN wording if err towards decessum - which i'm increasingly seeing as quite tenuous. What's really problematic as a consequence is that decessum is widely adopted in many sources (databases, pulbications etc), and to try to 'kill that' is going to be painful compared to what initially seemed simple to just get a few more of the Wiki stuff inline! What's really awful though is that lawyers get paid vast sums of money to interpret arcane wording in ambiguously worded codes, yet taxonomists just get grief! Sjl197 (talk) 06:36, 17 July 2024 (UTC)

Oak Island's map

Hello, I have a question regarding the Oak Island's map. The map on Commons corresponds to maps from Google Earth and OpenStreetMap.

We are :

• Smith’s Cove = south
• Sheerdam Cove = east
• Sellars Cove = north

These names are included on recent maps found on the web. But when we look for old plans, or in books about the island (page 7), we find:

• Smith’s Cove = east
• South Shore Cove = south
• Joudrey’s Cove = north

Which version is correct? Thanks, Sincerely --Tylwyth Eldar (talk) 15:43, 16 July 2024 (UTC)

@Tylwyth Eldar: why do you think one has to be more "correct"? Names often change over time. - Jmabel ! talk 21:19, 16 July 2024 (UTC)

July 17

Category:Flickr streams/Category:Photographs by Flickr photographer

You know. Wouldn't it be more efficient if these categories were populated by bots rather than users having to take time off to add the categories manually? Like all images whos author is listed as amaianos would automatically be placed into Category:Photographs by amaianos and etc.--Trade (talk) 00:42, 17 July 2024 (UTC)

@Trade: I'm sure no one would object to a bot filling in any valid category of this sort. Only caution: not every Flickr account corresponds to a photographer, and I've occasionally seen some wrong categories formed on the assumption that they do. - Jmabel ! talk 04:29, 17 July 2024 (UTC)

It's really annoying when you create a FlickR stream category for someone and they already have dozens of photos on Commons Trade (talk) 13:57, 17 July 2024 (UTC)

Agree. And there are more categories like that. The overly manual categorization also means that, at least over time, files are missing in categories when people think it contains all the files for a subject. For example take the category WebM videos which is still added manually and where I pointed this out here with some other example. One could list more examples and this issue relates to a technical idea to fix this issue that I would propose once there is some basic level of tech development or volunteer dev campaigning. If volunteer contributors time spent for such tasks is reduced, they can spend it on other contributions. Prototyperspective (talk) 09:57, 17 July 2024 (UTC)

"why categories for filetypes aren't automatically added". Because links are already overused in Commons. We just had a whole set of changes to reduce the amount of total links because Commons was reaching technical limits of the database. If you want to list video files, you can query the DB table for files, you can filter in the search results and sometimes, you can even use CommonsData. If Petscan doesn't support that... fix Petscan. —TheDJ (talk • contribs) 12:59, 17 July 2024 (UTC)

The fact that categories are easily and visible accessible to everyone and while things like DB tables, CommonsData and etc you have to go out of your way to search for already excludes most visitors and users on Commons.

It's a bizarre design choice if we are supposed to discourage the former in favor of encouraging the later Trade (talk) 14:01, 17 July 2024 (UTC)

I'm not sure what you're saying. Maybe you refer to categories which are links to their respective pages with "links [that are overused]" but I don't know. Filtering for video files only works for search results (especially with the MediaSearch) but not subject-level categories. Not every video about some subject has the search term of that in the title or description (or if it has not necessarily the English one). That would leave searching a category with deepcategory and filtering by filetype. However, that does not work on large categories. If it did, it would need to be made more accessible – subcategories "Videos of…" can be seen and simply clicked but there is no button/dropdown for seeing videos in a category. Yes, already created a petscan issue about it. Prototyperspective (talk) 14:28, 17 July 2024 (UTC)

Unsourced data on Commons?

I found a number of images of graphs without sources, and I now wonder if this is permissible on Commons. Two of the files are in use on itwiki, and no sources have been provided there either; if anything, the images themselves appear to be used as sources. So I hope you understand why I feel the need to bring this up.

I've sorted them under Category:Matrimoni religosi e civili (image set) and initiated a discussion at Commons:Categories for discussion/2024/07/Category:Matrimoni religosi e civili (image set). Sinigh (talk) 12:30, 17 July 2024 (UTC)

Commons is not Wikipedia, it doesn't have sourcing requirements (other than source of origin of the media for copyright reasons). See Project scope/Neutral point of view (mostly). —TheDJ (talk • contribs) 12:51, 17 July 2024 (UTC)

Add this template to such files: Template:Datasource missing and see Category:Information graphics without data source.

Something really needs to be done (I'm not saying they all should be deleted). I'm most concerned about files without source prominently featured in Wikipedia articles like File:Fertility Map.png or File:Projected Total Births 2020 2025.png. One could start with a GLAMorgan scan for files in that category that are used (the scan should run faster in a month or so) and discuss this on Wikipedia talk pages because it seems like nothing can be done from WMC side. Prototyperspective (talk) 14:56, 17 July 2024 (UTC)

Thanks! I should have been able to find that template myself. I agree with the current policy, but I think makes sense in cases like these to at least show users and readers that there's no source for the data presented. That too is educationally useful and informative, to say the least. Sinigh (talk) 15:33, 17 July 2024 (UTC)

That's why the template adds a red-colored infobox below the image. The Problem with that is people don't see it because Wikipedia shows images when clicking on them in a way that doesn't show much info from the WMC page. On Wikipedia, I think the respective image descriptions could be tagged with en:Template:Citation needed or similar templates and the WMC category could be a way to find them. Note that many of these use many different sources combined in one image but these should be specified in the file description and often also as refs where the image is used. Agree with you. Prototyperspective (talk) 15:38, 17 July 2024 (UTC)