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/06. Please note: If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer). Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam. Purposes which do not meet the scope of this page: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. Search archives:       Start a new discussion

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

Thatched water pump at Aylsham, Norfolk [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive How do we organize categories by date (14 May 2024) Proposal to prohibit political restriction templates (5 February 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 28

Category:Film characters by actors

Most of these categories contain no media of their own, but subcategories of characters (that are often played by multiple actors), and the structure is often circular in nature (e.g. the category "Whoopi Goldberg" has the subcategory "Whoopi Goldberg characters", which has the subcategory "Shenzi", which has the subcategory "Whoopi Goldberg"). Most if not all of these were made by the same IP user who created a huge amount of category spam in Category:Space Jam, Category:Mickey Mouse and a bunch of others.

I don't think this category tree structure is inherently invalid, but I feel it's mis-applied and excessive in most of these cases. I'd like to hear more people's thoughts on this before I take this to CfD though. ReneeWrites (talk) 19:19, 28 May 2024 (UTC)

The whole thing seems rather ambiguous and pointless. Like the parent is called "Film characters" but then the subcategories aren't even characters. Or maybe they are. Is a category like that suppose to be for "characters of Chris Rock" or "Characters played by Chris Rock"? It's not really clear. Then on top of it a lot of the sub-categories only contain one child category but no files, which I'm not really a fan of. --Adamant1 (talk) 19:49, 28 May 2024 (UTC)

I think this category structure is invalid, and these categories should be deleted. The purpose of categories on Commons is fundamentally to categorize media files. These categories don't organize media; instead, they attempt to represent abstract relationships between subjects. But that's what we have Wikidata for! We don't need to create a clumsy imitation of it on this site.

The same probably goes for the following categories, at a minimum:

• Category:Actors by role - the inverse relationship of "film characters by actors"
• Category:Films by actor - same concept, organized by films instead of characters
• Category:Films by shooting location - encoding minor facts about films into categories

Omphalographer (talk) 17:58, 29 May 2024 (UTC)

Most of the categories in Category:Actors by role were made by the same guy who filled Category:Film characters by actors and made the over 500 categories for Space Jam, Mickey Mouse, Scooby Doo etc. I took to CfD earlier. ReneeWrites (talk) 10:19, 30 May 2024 (UTC)

CfD plz Trade (talk) 15:59, 30 May 2024 (UTC)

@Trade: Created a CfD for Film characters by actors and Actors by role. ReneeWrites (talk) 19:29, 30 May 2024 (UTC)

Commons is not the place for this. Al Capone is not defined by Alec Baldwin and neither is Alec Baldwin defined by Al Capone. All of these categories should be deleted. The only place this data should be presented is in Wikipedia. Wikidata, might hold the names of movies and their casts, however that again is held in Wikipedia. We are not a repository of facts; we hold files, last time I looked. Only recently we had to go through this nonsense with film locations. Broichmore (talk) 12:20, 4 June 2024 (UTC)

@Broichmore: Could you link me to the discussion about film locations? Was there a consensus? ReneeWrites (talk) 20:31, 4 June 2024 (UTC)

Commons:Categories for discussion/2021/03/Category:Film locations by film (and the discussion which led into that, Commons:Categories for discussion/2020/11/Category:Film locations of Sonic the Hedgehog). Omphalographer (talk) 21:58, 4 June 2024 (UTC)

Thank you 🙂 ReneeWrites (talk) 22:05, 4 June 2024 (UTC)

Why is the category blue if consensus were to delete? Trade (talk) 02:42, 9 June 2024 (UTC)

Pinging @Pi.1415926535 as closing Admin.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:54, 25 June 2024 (UTC)

Because categories have to be tagged for deletion (and preferably emptied before you do). Having a consensus doesn't inherently lead to action being taken. ReneeWrites (talk) 17:43, 25 June 2024 (UTC)

@Trade: This is about a current discussion, not one that his been concluded. - Jmabel ! talk 15:27, 9 June 2024 (UTC)

Agree about the general problem, as mentioned above, the problem with Category:Films by actor from the United States (or Category:Films by actor) in general is similar.

The main question to solve is: where to place a picture of actor x playing the character y in the film z? In the three categories for each of these. Enhancing999 (talk) 17:27, 9 June 2024 (UTC)

Under the actor, the character (if we have such a category), and (if that character is not a subcat of the film) the film. If we have more than a handful of such images for the same actor in the same film, then we can make a subcat bringing the three together. - Jmabel ! talk 23:56, 9 June 2024 (UTC)

Laughingly Liam Neeson apparently played Hitler in a mini series. If we had a picture of him dressed up as Hitler, I certainly don’t want to see him filed under Hitler. Yes, under category Liam Neeson, and if we had one, for the TV series The latter should only have pix of the actual production, and in 121 years time, stills from the show, and the film itself. Broichmore (talk) 17:02, 16 June 2024 (UTC)

I think something specifically about actors playing Hitler, used only for images in that role, would be a lot better than the current Category:Adolf Hitler interpreters which consists entirely of categories about people, by name. - Jmabel ! talk 23:29, 16 June 2024 (UTC)

Every single "[Character] interpreters" category is like that. You can find them all compiled in Category:Actors by role and a CfD I opened for it last month at Discussion: Category:Actors by role where I made a similar argument about how to subcategorize actors playing specific characters. I also argued for all the "[Character] interpreters" categories to be deleted. ReneeWrites (talk) 08:03, 17 June 2024 (UTC)

Still another approach at Commons:Categories for discussion/2024/06/Category:Madras (film), where the category for an actor is a subcategory of the film, but we don't have any media related to the film itself. Possibly the same problem applies to any film category that only has subcategories. Enhancing999 (talk) 09:40, 20 June 2024 (UTC)

This is not that different from actors being subcategorized with characters they've played in films (see Category:Actors by role). It's actually the same problem. Broichmore put it really well in a comment he made earlier. To borrow his Al Capone example, Al Capone's not an appropriate subcategory of Alec Baldwin, nor is Alec Baldwin an appropriate subcategory of Al Capone. But once we have media on Commons of Alec Baldwin as Al Capone it can be added to both those categories. If we have enough media to justify creating a category for it on its own it can be named something like "Category:Alec Baldwin as Al Capone" and be made a subcategory for both of them. ReneeWrites (talk) 18:22, 20 June 2024 (UTC)

I don't think it's anything to do with Al Capone as such, your promoting clutter here. Al Capone in this context is a fictional character. This sort of thing is as pointless, as linking New York as a film location to 1000s of movies. When at core it's a member of only a very few cats, which define it. AC and AB do not define each other and never will. I suppose if, those against cats like this were to lose, then we would have to create a buffer cat to protect the principal cat, something like Portrayals of Al Capone in media. - Broichmore (talk) 14:33, 25 June 2024 (UTC)

Perhaps, we need to elaborate further in the rule book on what cats define a person. If we were to ask Al Capone on how he would define himself, he would volunteer the core set of cats we currently employ, Alec Baldwin would be a complete unknown to him. -Broichmore (talk) 11:50, 26 June 2024 (UTC)

Totally agree. I ran into a similar situation with artwork recently where images of windows are being put in categories for artists that just did minor restoration on the window. Which at least IMO clearly isn't correct. I'd say the same here. Images and categories for artists (which I'd consider actors as) shouldn't be associated with categories or images of works/people that they either had minimal to do with or aren't mainly known for. --Adamant1 (talk) 22:15, 26 June 2024 (UTC)

The hypothetical I put forward is of images being uploaded of Alec Baldwin playing Al Capone, assuming for a moment those images are alright to keep here. And if there's a lot of those images it's fine to make a subcat of that that can be both a subcat of Baldwin and Al Capone. I'm not talking about the movies as a whole, but specifically media that portray specific people. ReneeWrites (talk) 11:02, 27 June 2024 (UTC)

It's all related though. This whole thing is one big Markov chain lmao. --Adamant1 (talk) 12:37, 27 June 2024 (UTC)

An appropriate home for this kind of thing may be Wikidata, and or Wikipedia, if their willing to let you. I really don’t understand why you would want to make commons do something it’s not designed to do. This kind of data is of interest to general interest outlets, this is a databank, it’s not a forum or a social media platform. Even our gallery pages, I feel, are a complete waste of space. Broichmore (talk) 17:05, 29 June 2024 (UTC)

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)

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)

June 16

Wikidata sufficient for scope?

Hi, It seems unclear if creating a Wikidata item is sufficient for being in scope. Files were recently deleted when a WD item was created by the same user who uploaded the files. Here it concerns Commons:Deletion requests/Files in Category:Insane Ashraf. Yann (talk) 12:46, 16 June 2024 (UTC)

Wouldn't this better be asked at the Scope talk page? In COM:SCOPE it does say "legitimately" in use. That would mean it depends on the legitimacy of the Wikidata item itself and the legitimacy of the use there (does it actually show what the Wikidata item is about? is there a much better file available that should be used instead?). Prototyperspective (talk) 12:53, 16 June 2024 (UTC)

Actually these files and category were created by a sockpuppet farm, so I would delete for this reason alone. But the general question remains for future cases. Yann (talk) 14:49, 16 June 2024 (UTC)

It could be used to artificially cause a scope loop between Commons and Wikidata. AFAIK, Wikidata is the only Wikimedia website where an item can be in scope for no other reason than because it links to a page on Commons. A file about a person can be in scope on Commons if the file can be potentially useful to someone somewhere in a very broad educational sense, even if there is no page about that person on any other Wikimedia website. But that doesn't go so far as to include photos of non-notable persons in non-relevant contexts. Of course, a file about a person can be more easily assumed to be in scope on Commons if another Wikimedia website has a page about that person. (N.B.: that question is different and independent of the question of whether a file is in use or not on another Wikimedia website.) That makes sense based on the assumption that the other website has independent notability criteria. But that does not make sense when the only inclusion criterion being met on Wikidata by a person is that the Wikidata page links to a page on Commons. -- Asclepias (talk) 15:16, 16 June 2024 (UTC)

'Wikidata, has nothing to do with defining scope for Wikipedia or commons. Look to the policies for both projects separately to ascertain what is scope. There are differences, minor ones perhaps. Generally speaking, if it passes the scope test for Wikipedia. it will be okay for commons too, as the latter is marginally more liberal. As far as we are concerned, Wikidata is a tool, and nothing more. Broichmore (talk) 16:35, 16 June 2024 (UTC)

I'd think yes. I noticed in a recent cleanup exercice some stuff got tossed that was in use there, but that seemed relatively marginal. Enhancing999 (talk) 22:29, 16 June 2024 (UTC)

It seems to me that the only times an image that is used to illustrate a Wikidata item would be appropriate to delete on a "scope" basis would be (1) the Wikidata item shouldn't exist, which should first be dealt with on Wikidata or (2) the image does not meet Wikidata's criteria for images illustrating an item, which should first be dealt with on Wikidata. And, no, I wouldn't defend the case where the only justification for the Wikidata item is that the Commons image exists and vice versa.

@Broichmore: are you saying (above) that it would be appropriate do delete an image that is legitimately in use on Wikidata, or just that the presence of a Wikidata item is insufficient to justify having other images of the subject in question? I'd agree with the latter: I believe there are cases where there are Wikidata items for every name on a war memorial or every person buried in a particular graveyard. That would merit hosting a single image of any of these people to support Wikidata, but would not mean that we would want an open-ended number of images of each such person. - Jmabel ! talk 23:44, 16 June 2024 (UTC)

@Jmabel: Not to speak for Broichmore, but read through Wikidata:Requests_for_deletions#Q125118469. Especially the last 4 or 5 comments. I assume it's similar to what Broichmore is talking about. --Adamant1 (talk) 23:59, 16 June 2024 (UTC)

As your all too aware, criteria for uploading images on commons centres on copyright (we want only PD), modified by notability, the emphasis on the former.

In Wikipedia, it's possible to upload a non-PD item (using, the fair use parameter), if there's no other image (of even dubious suitability) available. Even so, the item then needs to be degraded so it's worthless commercially. Only items, most representative, are entertained. A pix of the ship. The person's face. an LP cover. An actual passport style portrait of the item.

Wikidata says it wants an image of (the) relevant illustration of the subject; if available, use more specific properties (sample: coat of arms image, locator map, flag image, signature image, logo image, collage image); only images which exist on Wikimedia Commons are acceptable. In other words only PD and no fair use.

Briefly, again, wanted images for the Wikipedia infobox and wikidata are passport only portraits, in that spirit I've been known to crop out portraits for that purpose. This example was used for both projects. That portrait will be replaced, only when better surfaces.

Wikipedia carries only one pix in its infobox, and so should Wikidata, however the latter can carry more. Perhaps a persons facial image, representative from different stages of their life. There's no real limit. I don’t think this has actually been tested, by abuse yet, the tacit acceptance is, use only one image, perhaps two, following Wikipedia guidelines.

Wikidata’s scope for inclusion is immense in comparison to WP and commons. Briefly an item should be represented by at least one valid sitelink to a page on Wikipedia, Wikivoyage, Wikisource, Wikiquote, Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity, or Wikimedia Commons. ’’Note it refers to itself, it’s a bit woolly. But it wants to tag everything useful in the world. Read the policy here.

As I see it, Wikidata has three uses for us, first our infobox, containing the variables that dictate licensing, secondly (for an artist, if there's no WP article); locations of work by time period, useful for correct attribution, and third, disambiguation of artists or place names. Broichmore (talk) 11:07, 17 June 2024 (UTC)

It doesn't help there that the user whose contributions are largely at issue keeps cycling back and forth between reasonably serious arguments, ad hominem remarks, and remarks that seem entirely intended to derail the discussion. But I stand by what I wrote above: circular justification doesn't cut it; a Wikidata item can justify keeping one photo on Commons that would otherwise be deleted, to function as an image for that item; and it isn't up to us on Commons to decide whether the item meets Wikidata's (generally lower) threshold of notability. - Jmabel 01:09, 17 June 2024 (UTC)

The "scope loop" breaks on the Wikidata side. Per d:Wikidata:Notability, "Category items with a sitelink only to Wikimedia Commons are not permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)". Commons can expedite the cleanup of objects involved in these loops by ignoring media uses on Wikidata which only refer back to Commons. Omphalographer (talk) 23:56, 16 June 2024 (UTC)

Concur. WD item creation that is involved with the uploader/creator in sequence within the same timeframe, and otherwise fails their notability (articles or independent linkage) is not "in use" (image or category). If it is borderline, or where I am in doubt, I will nominate there for deletion with appropriate commentary, and then nominate the image here with a DR, so we can do some follow-up (our DR review takes longer than theirs). That is pretty much what I will do for a draft article where it is dodgy and reeking of COI at the WPs.  — billinghurst sDrewth 04:38, 17 June 2024 (UTC)

@Omphalographer: that seems more of a technicality about WD than something germane here. It's specifically about Category items. That just means that if you are making up (for example) an item about Person FOO and the only Category:Person FOO is on Commons, you can make an item about "Person FOO", but not about "Category:Person FOO". - Jmabel ! talk 06:38, 17 June 2024 (UTC)

@Jmabel, actually, you could, if "Person FOO" is sustainable itself. The item for "Category:Person FOO" is allowed per criteria #3 as structurally required as the topic's main category (P910) for the former item. What is not allowed is if "Person FOO" does not exist on Wikidata, and you solely wanted to create an item for "Category:Person FOO" with the only sitelink being to the Commons category. That would fail all three of the criteria for notability there. Of course, as you stated, this is all applicable to Wikidata alone and has no real relevance to Commons, except that you probably shouldn't add {{Wikidata infobox}} to "Category:Person FOO" without a valid corresponding Wikidata item. If that category is a valid Commons category, we certainly should not delete it just because it does not support a Wikidata link. Josh (talk) 17:08, 17 June 2024 (UTC)

@Joshbaumgartner: No. I have no idea of your level of experience on Wikidata (and feel free to correct me if that experience is extensive, and you can provide examples of something I've never seen), but in my experience no one goes around creating a "category" item just to use it within Wikidata for a topic's main category (P910). Otherwise, every item would get a corresponding "category" item. Hell, every category item could get a corresponding, totally useless "Category:Category" item, etc. ad infinitum. Until a "category" item is justified by the existence of categories on some sister project other than Commons or Wikidata itself, it should not be created. - Jmabel ! talk 19:29, 17 June 2024 (UTC)

Why in the world would anything require a "Category:Category" item? That doesn't make any sense. I honestly have no idea what tangent you are off on here. Wikidata supports an item for the Topic (with sitelinks to articles and galleries) and an item for Category:Topic (with sitelinks to category pages). The Category:Topic item doesn't need any more than the sitelink to its Commons category to be valid according to WD:Notability. By the way, I wouldn't make any personal claim of being especially experienced at Wikidata, I only have 750,000+ edits there and have been a property creator since they were still in double-digits, but my lack of experience is moot, WD's notability guidelines don't require an experienced editor to understand. Josh (talk) 01:41, 28 June 2024 (UTC)

@Joshbaumgartner: Please don't take my reductio ad absurdum for a serious proposal! Quoting the very page you mentioned, wikidata:WD:Notability: "Category items with a sitelink only to Wikimedia Commons are not [emphasis mine] permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with equipment (P2033)." - Jmabel ! talk 02:29, 28 June 2024 (UTC)

@Jmabel Fair enough, but I'm curious why you are intentionally re-quoting that section out of context. Why are you not indicating honestly that the section you quoted is only a sub-section of criteria #1 in the notability test and additionally that an item only needs to pass 1 of the 3 notability criteria to pass Wikidata's notability guidelines? Re-quoting this section without that context as if it were some overarching rule that applied to all notability tests is misleading in the extreme. I was a bit disappointed at seeing this from you, as I expect a higher standard from you, Jmabel. I'm assuming good faith in that you did not intend to be misleading, but hopefully you are willing to correct this oversight? Josh (talk) 02:41, 28 June 2024 (UTC)

@Joshbaumgartner: I don't believe that was out of context; I certainly wasn't going to quote the entire page. I normally respect your work, but I honestly cannot work out what you mean here. Are you saying that every Wikidata item A should have a corresponding Wikidata "category" item B just so B can be linked from A with topic's main category (P910), when B serves no other use? If so, then we are back to the absurd infinite regress I laid out: by that same logic B can also have a topic's main category (P910) linking a (ridiculous) "Category:Category" item C, etc., etc., etc. If you were saying neither that nor that the Commons category is enough on its own for Wikidata notability, I honestly cannot see what else you could have meant, but please feel free to elucidate. - Jmabel ! talk 03:27, 28 June 2024 (UTC)

@Jmabel You do seem fond of trying to reduce things to absurdity instead of dealing with what is actually being said. No one asked you to quote the whole page, and no one has proposed or done creation of "Category:Category:Cate..." items. Do you really think that no "category item(s) with a sitelink only to Wikimedia Commons" can ever pass notability, or do you agree that clause only applies in some circumstances, and that in many instances, "category item(s) with a sitelink only to Wikimedia Commons" are perfectly valid per WD:Notability? You quoted the clause as if you believe the first case, that it is an absolute rule, as you intentionally (per your admission) omitted providing any context to the quote. Which is it? Josh (talk) 03:54, 28 June 2024 (UTC)

@Joshbaumgartner: Here's my understanding. Again, I may be wrong, but I haven't seen a counterexample. As noted within what I quoted there are two cases where there can be a valid category item where the only corresponding category is on Commons. (1) There is a corresponding Commons gallery (in addition to the category). (2) There is a structural need for the category for a Commons-related statement (but the example you gave of topic's main category (P910) does not constitute such a structural need). But that's it. Other than that, a "category" item is justified only by having a category on a sister project other than Commons. Or to put it another way, there are exactly three cases that justify creation of a "category" item:

1. There is a corresponding category on a WMF sister project other than Commons.
2. There is a corresponding category and a corresponding gallery on Commons.
3. There is a structural need for the category for a Commons-related statement.

If there is a valid "category" item that does not meet one of those three criteria, I'm not aware of it. Can you give an example? - Jmabel ! talk 04:15, 28 June 2024 (UTC)

Or are you just talking about things like the item for the separate category for the name of a ship? Yes, of course those are OK, because the Wikidata modeling approach requires them. - Jmabel ! talk 05:09, 28 June 2024 (UTC)

So yes, you can have a Category item where the only sitelink is to a Commons category. Thank you for agreeing on that point. Your assertion that somehow topic's main category (P910) doesn't count as a structural need is rather silly and made up, but whatever, it doesn't matter for this conversation. All we care about on this side of the fence is that yes, sometimes a Wikidata category item will exist with the only sitelink being to a Commons category and so if we are going to base our scope policy in any part on the existence of such an item (I disagree with doing so, for the record), then we have to keep that in mind. Josh (talk) 05:14, 28 June 2024 (UTC)

@Omphalographer, note that only applies if attempting to sustain notability under criteria 1 (i.e. solely on the basis of a sitelink). If an item qualifies under criteria 2 or 3 (i.e. is a "clearly identifiable conceptual or material entity that can be described using serious and publicly available references" or "fulfills a structural need"), the exclusion of 'items with a sitelink only to Wikimedia Commons' is not applicable. Josh (talk) 16:58, 17 June 2024 (UTC)

For people, I think it'd be acceptable to declare as in scope those items with an identifier that may presume the subject is notable or relevant, such as those of National Libraries. Bedivere (talk) 20:41, 20 June 2024 (UTC)

@Bedivere That's an issue for WD to decide. I am pretty sure anyone with an ID from a recognized authority (i.e. one with a relevant ID property) is going to be considered in scope on WD. Josh (talk) 01:44, 28 June 2024 (UTC)

@Omphalographer The "scope loop" ought to be broken in Commons policy too so that we can achieve the right result on a file here without having to wait for an action in another project. Consigned (talk) 23:21, 21 June 2024 (UTC)

@Consigned: strongly disagree. Legitimate use on a sister project should be sufficient reason to consider an image to be in Commons' scope, and we should not be in a position to dictate to other projects what we consider legitimate for them. Commons is, as much as anything else, a repository for images required by other projects. Wikidata, for example, does not host images itself, and completely relies on Commons to be its image host. - Jmabel ! talk 02:03, 22 June 2024 (UTC)

You could argue that images are tangential, if not completely at odds, with the purposes of Wikidata as a project though. I don't think the same could be said for Wikipedia since encyclopedias historically included images, but there's nothing about tabled or linked data that has anything to do with media. In most cases it has absolutely nothing to do with Wikidata being a "knowledge base of structured data" or whatever. I don't think we are obligated to host an image of something, let alone specific types of media, just because someone creates a Wikidata property or item for it either. --Adamant1 (talk) 02:26, 22 June 2024 (UTC)

@Jmabel: If item on WD is within their scope and the notability, then yes, any image is reasonable. That said, there are many who upload an image, then create an item there as self-promotion, so in those cases it is not reasonable to retain. Solely having an item there, and having an image here used there, should NOT be the sole criteria, we need to have a little investigation. We cannot have each site be a blocker to the other resolving spam and self-importance.  — billinghurst sDrewth 12:38, 22 June 2024 (UTC)

@Billinghurst: agreed on the problem, but Wikidata, not Commons, is where you have to fight to say something on Wikidata is not valid use. Yes, every sister project is in this sense a "blocker" because we are here, among other things, to serve those projects. Again, we can consider something spammy, but it is up to Wikidata to make their own determination about their notability threshold, which is a low threshold. Having an item exist on Wikidata isn't an argument to keep 14 photos of that subject; it isn't an argument to create a category for that subject; but it is an argument for keeping the photo Wikidata is using. If Wikidata decides that the subject is above their threshold of inclusion, then the are entitled to have one photo of it, and Commons is the only place that can be hosted. - Jmabel ! talk 16:54, 22 June 2024 (UTC)

@Jmabel: Please do not make this into a Gordian knot or an ouroboros; WD is also here with a level of serve the projects, hence their first point in d:Wikidata:Notability. NOTABILITY 1a) For an item to be notable at Wikidata there are numbers of hoops, and the main one for that is that a SITELINK exists. NO files at Commons are sitelinks at WD, that is only to galleries and categories, and that is the zone that we control. [Note that having an image is not a notability criteria.] 1b) The item has to have a range of other criteria including links to other items, and links to the item. 2) We are all editors at Commons and Wikidata, so I am more than comfortable identifying an abuse of process of the two, and ask for the file to be deleted, and for the WD item to be deleted. At this end, I have more investment in the deletion process and involve myself from both sides, and both methods DR and Speedy; whereas I leave things up to them for their processing. 3) If there is a level of wait for their processes to flow, then I nom there, and DR here with comment about awaiting resolution at WD and we have enough lag that it will resolve one way or the other. Imperfect, though it gets rid of most dross. At that point, if they make the decision to keep, then so do we. It doesn't prevent us having some rigour and challenge the dross.  — billinghurst sDrewth 23:43, 22 June 2024 (UTC)

This is (or at least started out being) a discussion about deletion of files, not about categories. Of course we can get rid of a category even if it corresponds to a Wikidata item. Similarly, in theory, we can get rid of a category even if it corresponds to an article in the English-language Wikipedia, or in any number of Wikipedias, though we seldom do, even for categories with only one photo. But (barring copyright issues) we should not be the ones to get rid of a file that is being used by a sister project without first resolving that use on the project in question. And, yes (give or take a few people who are blocked) people here on Commons may participate in whichever of these sister projects they choose, but these projects are distinct overlapping communities that do not always reach the same consensus on everything. - Jmabel ! talk 00:16, 23 June 2024 (UTC)

Wikidata has what they concurred to be a "common sense" conflict of editing policy. They are regularly deleting conflicts of interest, and components of self-importance. An image uploaded here and an item created at WD by the same person and neither has an editing history at Commons or WD, clearly aligns with the F10 criteria here, and there should be a deletion process. There is no 100% purity, so applying good sense to interpreting our clear principles here and there, and let the community manage attempts to abuse us. The UDR process is here to be used by anyone who thinks that there is a mistake, so we can have resolution as required. We are never going to be perfect, and we have a resolution process.  — billinghurst sDrewth 01:47, 23 June 2024 (UTC)

June 22

Disease-related deaths in Beijing

Everything, I sampled in Category:Disease-related deaths in Beijing, is complete bollocks.

Executions, airline crashes, and old age are not Disease-related. Looks like vandalism to me. What to do? Broichmore (talk) 18:14, 1 July 2024 (UTC)

June 24

Why are we doing this? (Reasons why WMC is useful)

In the context of discussions relating to Commons:Media knowledge beyond Wikipedia I created an initial version of a list of reasons why Wikimedia Commons is useful or ways it could be used for. You're invited to participate at Commons:Why Wikimedia Commons is useful and add any usecases/reasons that are currently not on the page.

Adding more concrete illustrative examples or barriers usefulness-types would also be helpful. I think such a list could make WMC more useful than it already is, communicate the value of it to relevant people (e.g. people considering freeing their collections or contributing), and raise awareness/activities of users that eventually raise WMC's value and our work here to the world. Things can also be discussed on its talk page. Prototyperspective (talk) 14:26, 24 June 2024 (UTC)

It has grown a lot recently and probably needs subsections now. Maybe another place would be better to ask about this. I think identifying and improving upon reasons for usefulness is pretty important so it would be best if more users contributed to the list. Prototyperspective (talk) 10:09, 28 June 2024 (UTC)

@Prototyperspective: I'm not exactly sure where to put it on your list or if it's already been covered, but I've been using galleries to create catalogs of postcards by particular publishers. For instance Postcards published by Edward H. Mitchell. I think this might be the only website doing anything like that. As well the only one where it would even be fusible due to it being a repository of media from a large number of multiple sources across the globe. I guess there's similar things on here like galleries of stamps, but I think the ones for postcard publishers are fairly novel. Logos of postcard publishers is a similar project. It's possibly the biggest gallery of logos for postcard publishers in the world and I'm sure it couldn't have been created anywhere else. --Adamant1 (talk) 11:19, 28 June 2024 (UTC)

I think it's covered mostly by "Central repository of collaboratively organized structured media" and also "Enabling finding lots of or highly specific media". In general the subject is how what people are doing or making available is useful, not that itself (as in aggregation and organization).

So one would have to think about and specify how such galleries/catalogs may be useful to users (that could be entertainment, research, educational purposes, and so on)...e.g. this is not about unique valuable things available or enabled by WMC but how (why) these are useful. The usefulness of the two mentioned ways is elaborated next to these points and probably still needs further expansion, these are not as clear/specific as many of the other cases such as "Finding media for illustrating a given Wikipedia article". Prototyperspective (talk) 11:33, 28 June 2024 (UTC)

Uuuhhh...OK. That makes sense. Sounds like it could be elaborated and expanded. --Adamant1 (talk) 11:36, 28 June 2024 (UTC)

There are sections now and sooner or later I'll (most likely) will also add some studies there. Uncommon use-cases however will be hard to identify so if you ever used in WMC in some way not included there please add it or describe it on its talk page.

I think the more media there is on WMC, the more gaps of media are filled (especially various illustrations or simple things like brief videos/animations of how to execute particular fitness exercises) and the more organized it is, the more usecases there will be or the more valuable these will become. Prototyperspective (talk) 11:57, 4 July 2024 (UTC)

It feels like we could add some other languages --PantheraLeo1359531 😺 (talk) 18:02, 4 July 2024 (UTC)

A new research report on Cross-wiki uploads have been published

Hello all! I'm happy to announce the publication of the UX research report called "Cross-Wiki Uploads on En and Ar Wikipedias". The research, conducted in collaboration with the Structured Content team, was aimed at understanding how users were interacting with the Visual Editor upload tool. We hypothesized that the UI may contribute to users uploading files as "own work" when the work is not theirs. What we found is, indeed, users are erroneously uploading files as "own work".

Some of the findings of the report are:

• 14 of 16 users interviewed from English and Arabic wikis uploaded others work as their own, and only a few of those files had been moderated. So the problem is much larger than documented.
• This is partly because users interpret "own work" differently, so many believe they have the authority to upload when, according to copyright rules, they do not. This is also because the UI does not present alternative options in a way that users understand (the text on the UI is very confusing to them).
• There is widespread confusion about what is/isn't allowed to be uploaded, what constitutes copyright, who holds the copyright, and how does that relate to Creative Commons licenses. The image policy is not accessible or known to users.
• Interestingly, we found that most uploaders were either marketers (editing/uploading on behalf of another entity such as their employer), or they were self-promoters (creating pages about themselves, unaware of the "notability" requirement).

See the full report for details, more key findings, and recommendations. Also feel free to comment on it in this thread. Hope this will help in your work! Sannita (WMF) (talk) 14:34, 24 June 2024 (UTC)

@Sannita (WMF) a good research! It is timely, considering that I opened a similar issue regarding some problematic cross-wiki uploads (also through the regular VP forum, I think it is still here – not archived as of this posted comment).

Some two thoughts of mine. Re: "The 'upload page on Wikipedia' statement is the most confusing of all," I think it is due to the general public perception that both Wikipedia and Wikimedia Commons are same, as a single platform for educational content, even if both are different websites that happened to be under the umbrella of Wikimedia Foundation. No matter how we try to educate people about the differences in policies and scopes of the two websites, a layman will still treat both as identical; or, as one website. Even the anti-Wikipedia group ADAGP who opposes FoP does not use "Wikimedia Commons" in their presentation to the EU Parliament in 2015; they used "Wikipedia" instead. Perhaps the upload forms should use understandable, layman's language.

Re: "Participants don't know what to do with files that are not their own creation," I guess a massive copyright education campaign is needed. Explanations should not use excessive legalese or technical terms. For Wikimedia groups and affiliates, reforms to copyright laws must be pushed to simplify things. Much of the complexity of copyright for an average layman is due to the complex copyright laws. JWilz12345 (Talk|Contrib's.) 16:42, 24 June 2024 (UTC)

10 out of 11 English users were promotional - 5 self-promotion and 5 marketing. Only one of those 10 was notable enough to be in scope, and even then it appears there were copyright issues. The problem here is not the UI; the problem is that the entire cross-wiki upload system makes it much easier for spammers without providing much benefit to anyone else. At minimum, cross-wiki upload needs to be turned off from the User: and Draft: namespaces (where most of the spam comes from). Pi.1415926535 (talk) 18:52, 24 June 2024 (UTC)

I would also say before investing much time and therefore money in improvements for the cross-wiki upload we should discuss if we want to give cross-wiki upload a chance or if we want to block it entirely to not approved (autopatrol or similar on other wikis) accounts. GPSLeo (talk) 18:59, 24 June 2024 (UTC)

Second in motion to @GPSLeo's suggestion. Cross-wiki uploading had good intentions, but is easily abused. Perhaps only allow cross-wiki uploading to users who are among one of these user groups: admins/sysops, license reviewers, and autopatrolled users. Cross-wiki feature should be treated as a right with burden of responsibility to the uploader. I'm not in favor of axing out the feature entirely. JWilz12345 (Talk|Contrib's.) 02:44, 25 June 2024 (UTC)

@JWilz12345: How would that work with people having different privileges depending on the site? --Adamant1 (talk) 02:46, 25 June 2024 (UTC)

@Adamant1 Commons user rights will be the basis for it. Users should have familiarity on Commons policies and project scope. Their uploads should comply our house rules. JWilz12345 (Talk|Contrib's.) 02:54, 25 June 2024 (UTC)

We really, really need some process and tools such that, when files are cross-wiki uploaded and don't remain on the page they were uploaded for (e.g. because the edit adding them was reverted, the page was deleted, or the user never completed an edit adding the image), those files can be identified and deleted from Commons with a minimum of hassle. Right now, there's no good way to spot those images, and deleting them will usually require a DR. That's a lot of overhead to get rid of a file which the uploader may not have ever expected to persist on Commons. Omphalographer (talk) 19:11, 24 June 2024 (UTC)

@Omphalographer sometimes DRs aren't needed at all. Speedy deletion tag is the key, if evidences gathered from Google Lens and TinEye searches are convincing. JWilz12345 (Talk|Contrib's.) 02:51, 25 June 2024 (UTC)

For images which are copyvios, sure. But that's an orthogonal concern. Omphalographer (talk) 03:33, 25 June 2024 (UTC)

@Omphalographer: there is something like that but it is currently limited to only en-wiki rejected drafts: https://heber.toolforge.org/drafts/filter/20240624. MKFI (talk) 07:39, 25 June 2024 (UTC)

The problem isn't the process, the problem is the backlog of likely millions of files that violate existing, sensible policy (no copyvios, no unusable personal photos) scattered around the project. Identifying these and checking for prior usage/checking user contribs takes time. Gnomingstuff (talk) 05:27, 26 June 2024 (UTC)

cross-wiki upload should probably just be blocked outright at this point. As it's clearly an issue that has no easy, implementable, solution. At least not in the short-term. IMO there really needs to be a more clear separation between the projects for something like cross-wiki uploading to work. It's never going to "fixed" if everyone using it just thinks Commons is a glorified subdomain of Wikipedia though. --Adamant1 (talk) 22:28, 24 June 2024 (UTC)

Agreed. Would also solve almost every problem mentioned in this thread at once. ReneeWrites (talk) 19:20, 26 June 2024 (UTC)

Just about the logo question: maybe the study sees this too much from a Commons' perspective, despite studying English Wikipedia and people contributing to articles there: personally, I think the default recommendation should be to upload a logo for "fair use" directly at enwiki. Enhancing999 (talk) 22:46, 24 June 2024 (UTC)

Yup. Possibly combined with a "logo" branch in a Wizard that tries to work out what is the relevant country, then describes the relevant threshold of originality and asks whether it is clearly above (keep it local), clearly below (go to Commons) or just plain unclear (keep it local, which is safer). Also, logo + "own work" is almost always wrong, though of course it is very occasionally correct. - Jmabel ! talk 23:08, 24 June 2024 (UTC)

Of course, some Wikipedias don't allow "local"… - Jmabel ! talk 23:09, 24 June 2024 (UTC)

It doesn't seem like English Wikipedia wants to host images of logos going by the number we have, but that would be the better solution. Although it would then screw over the ability of other projects to use the files in a lot of cases. So maybe it's not the best way to go about this. --Adamant1 (talk) 23:16, 24 June 2024 (UTC)

en-wiki routinely hosts logos that are over the threshold of originality, if they have an article about the organization in question. - Jmabel ! talk 23:29, 24 June 2024 (UTC)

Sure, I was mainly saying it in jest, but we do host a lot of logos that have been sent over from Wikipedia for one reason or another. --Adamant1 (talk) 09:11, 26 June 2024 (UTC)

About the "personal images": not sure how the study gets to that conclusion of it being a big issue. If in a sample group people were writing autobiographies about their not-Wikipedia notable selves, why should they consider that their image isn't suitable to be uploaded despite serving as an illustration to the article? If the article actually exists, the image can be uploaded. Also, the subject of an article is the most likely person to have access to correctly licensed or licensable images. Obviously "personal images" can be an issue at Commons, but this may be unrelated to enwiki articles. - Enhancing999 (talk) 09:30, 25 June 2024 (UTC)

@Enhancing999 may be because images that show the uploaders themselves are only falling within the house rules of Commons, if they serve real purpose like Wikimedia-related activities, uses on user pages in all wiki sites, and in an article (if the article survives the review process of other editors). Assuming an image does not have the purpose of documenting Wikimedia-related events, and it is not used on a userspace page, and it is being used in an article on English Wikipedia. The article is then slapped with AfD request. The article is found to not comply with w:en:WP:GNG (especially on BLP house rules there) and is "sentenced to death". With the article deleted, the image then becomes an "out of scope image" or "unused personal image". JWilz12345 (Talk|Contrib's.) 12:15, 25 June 2024 (UTC)

Where is that in the study? Enhancing999 (talk) 05:33, 26 June 2024 (UTC)

•  Comment I hate to have a hot take here, but this (and the whole thing with using AI to identify logos) assumes uploading COPYVIO is even a problem to begin with. It's not like we can't (or don't) delete copyrighted images pretty regularly. Maybe it's secondary to the core principles of Commons, but doing so has the benefit of being able to document artists and dates works become PD. There's as much value in that IMO then automating to the point of stopping people from uploading COPYVIO or really anything because they are so turned off by the warnings. Regardless, we are here to document, preserve, and "maintain" a media repository. Which inherently to some degree depends on people uploading COPYVIO once in a while (if not regularly). The important thing, and I'd argue the current issue that things like this are getting at, is that we should be able to deal with it in a timely manor. Not that it shouldn't exist in the first place. --Adamant1 (talk) 06:05, 26 June 2024 (UTC)

  I get what you're saying, but we're very much at "regularly" and arguably at "frequently." The copyvios that are uploaded, and certainly the ones talked about this thread, are usually recent enough that they won't enter public domain within any of our lifetimes. Gnomingstuff (talk) 18:58, 26 June 2024 (UTC)

• Related to this, but not really mentioned in the study, I was wondering if the mere upload function of "cross-wiki uploads" is technically superior to the other upload tools. Please see Commons:Village_pump/Technical#Upload_functions_used_by_various_tools (you may want to comment there). Enhancing999 (talk) 10:29, 30 June 2024 (UTC)

• For a proposal following the study and its review in this thread, please see Commons:Village_pump/Proposals#Deactivate_cross-wiki_uploads_for_new_users. -- Enhancing999 (talk) 10:35, 30 June 2024 (UTC)

June 26

Example of SVG with hyperlinks

Hey, can anyone give me an example of an SVG with hyperlinks in so that I can check the syntax? Thanks. — Scott • talk 10:37, 26 June 2024 (UTC)

File:SVG Gradient.svg has a use element.

SVG 1.1 uses xlink:href. WMF uses an SVG 1.1 rasterizer, so SVG elements such as use must employ the xlink namespace.

SVG 2.0 allows either xlink:href or href. Most browsers are compliant with SVG 2.0, so viewing the SVG directly in a browser will work with either form.

Glrx (talk) 15:39, 27 June 2024 (UTC)

Thanks! — Scott • talk 08:53, 3 July 2024 (UTC)

Engravings and Lithographs etc.

We have a gigantic epidemic of people overwriting existing Engravings and Lithographic images with different versions of the same image. Also, the same for cropping off captions and border, without creating new files.

18th and 19th century Lithographs and engravings are all unique, even if they come from the same book and edition, they are different, in terms of condition, printing, edition source, and hand painting, and they should not be overwritten by anything other than the exact same print, from the same book, from the same museum or owner.

Lately, I try and protect them with Template:Border is intentional, but I'm overwhelmed at the amount of damage done. It's a losing battle.

These images need the artwork template and we need to some means of ensuring that files are not overwritten with similar, but different images. Are there other templates that can be used.

Can we put in bot measures to protect them, from these oafs? It's bad enough with these people omitting descriptive detail, using dubious sources (that steal images from elsewhere in the net), and claim false ownership. Not to mention all the AI crap, that’s, no doubt on its way.

What extra measures can we employ? Broichmore (talk) 14:54, 26 June 2024 (UTC)

• Even when overwritten, they are still there. --RAN (talk) 17:07, 30 June 2024 (UTC)

  That's not the point, if they are overwritten, they are unavailable for use! Also, they cannot be easily assessed, for use, as they are hidden and require drilling down to see.

  Sometimes end users want a unique image for their website, variety is a desirable thing. Broichmore (talk) 18:03, 1 July 2024 (UTC)

"Stained glass" versus "stained-glass"

It seems like the usage of a hyphen for categories having to do with images of stained glass is all over the place. The main category and Wikidata are named without a hyphen but then it seems to quickly break down from there with a good portion of sub-categories using one. Personally I prefer no hyphen, but there seems to be a consensus at least in how many use it versus don't that it's the preferred way of naming things. Anyone have a preference or know which is better? Adamant1 (talk) 22:26, 26 June 2024 (UTC)

"stained glass" as a noun, "stained-glass" as an adjective (e.g. "stained-glass window"). We had this discussion a few years ago, and that consensus was pretty clear. - Jmabel ! talk 04:45, 27 June 2024 (UTC)

@Jmabel: So just to be clear the consensus is for there to be no hyphen then? --Adamant1 (talk) 01:33, 29 June 2024 (UTC)

@Adamant1: No. The category Category:Stained glass is correct: a single adjective ("stained") modifying the noun "glass". There is no ambiguity about what "stained" modifies: it modifies the noun "glass". The category Category:Stained-glass artists is correct. The adjective "stained" should modify "glass", and that is signaled by using the hyphen. If there were no hyphen, then "stained" might modify "artists". Glrx (talk) 02:59, 29 June 2024 (UTC)

June 27

GLAM uploads

Are GLAM uploads always once off? Or does Wiki commons have functionality to allow synching of a GLAM database?

Automated interfaces tend to have functionality -

• At Origin : a trigger job waiting for a change,
• Data cleansing - rules, error handling
• Trigger for transmission - every week, every n records..
• Mapping- a mapping tool of Origin to Target, reuse of maps from the same system, mapping version, envelopes with sequence numbers
• Transmission - path, passwords, encryption, confirmation of receipt, checksums
• At Target - transmission triggers upload into target, error checking
• Error checking that database matches

(Asked a similar question about wiki data with no answer) Wakelamp (talk) 06:06, 27 June 2024 (UTC)

Most likely it depends on uploader and tool used as most GLAM databases are different in terms of content, interfaces etc. Afaik most uploads are made by custom scripts and and solutions are made in upload tool level. Wiki commons itself doesn't have functionality to sync with external GLAM repositories. --Zache (talk) 18:56, 27 June 2024 (UTC)

Repeated uploads from the same GLAM are quite common. Synching is actually a bit trickier than you might think. I have some experience with this from the point of view of curating the content brought in from a GLAM by a bot. I'll try to get back here and share my thoughts in that in a day or two if no one else has something solid. @Wakelamp, feel free to hit my up if this slips my mind. - Jmabel ! talk 23:50, 27 June 2024 (UTC)

A few considerations:

1. In deciding whether to upload automatically, you don't just want to consider whether the file is on Commons. You should track what has already been uploaded, because if the bot uploaded it before and it is not on Commons now it was probably deleted and, rather then upload, you would want a report to a human who can make an informed decision.
2. If metadata has changed at the GLAM and the original upload has never been touched on Commons, then it is reasonable to bring the corresponding data on Commons up to date. However, if the corresponding data on Commons has been modified in any way, again we are into a situation where a human should make a decision. It is possible that the change/correction on Commons is better than the one at the GLAM. For example, a GLAM may have made a minor correction in a description where someone on Commons has done a good job of fleshing it out.
   • This one gets complicated if another bot is (for example) copying data from wikitext to SDC, one of many reasons why it is good if the upload bot can fill in both wikitext and SDC where both make sense to use.
3. I would recommend always having at least two hidden categories added to every file uploaded by a bot from a GLAM:
   1. A source category (e.g. Category:Files from Southern North Dakota History Museum), with at least Category:Source categories (flat list) as a parent
   2. A second category (e.g. Category:Files from Southern North Dakota History Museum (check needed), with at least Category:Files by source to be checked as a parent

User:Dominic has done a fair amount of uploads along these lines. I don't know how well his uploads conform to what I've written above, but I imagine still that he will have some useful things to say if he chooses to weigh in. - Jmabel ! talk 04:26, 1 July 2024 (UTC)

@Wakelamp btw, why do you ask? (ie. do you have some specific use case like you would like to do uploads or are you just curious to know what kind infrastructure there is) --Zache (talk) 19:16, 1 July 2024 (UTC)

As mentioned above, be careful not re-upload already deleted files. Also, you might need to keep track of file renames and possible tags for problems on these files (some may be about trivial issues, others not). Enhancing999 (talk) 20:07, 1 July 2024 (UTC)

June 28

YouTube has stopped displaying CC lincenses

I have just found today that YouTube changed the page layout and CC lincenses are no longer being displayed. --トトト (talk) 06:42, 28 June 2024 (UTC)

Uugghh well that sucks. I think I nominated a couple of videos for deletion a few days ago because the link to YouTube didn't say they were CC licensed even though that was the claim. Great. --Adamant1 (talk) 06:48, 28 June 2024 (UTC)

@トトト: That's curious. When I go to https://www.youtube.com/watch?v=OYCjGfQJ4kw (a video I happen to have uploaded a screenshot from) and click "...more" at the end of the description, the expanded description still contains "Licence Creative Commons Attribution licence (reuse allowed)". Does it appear on that video for you? Have you got a different example where it doesn't? --bjh21 (talk) 09:53, 28 June 2024 (UTC)

What do you mean? I still see the license just like before at the bottom of the video description next to License and one can search for videos with that license using filters.

On a related note, sometimes I think youtube deboosts videos with CC-licenses (maybe because they aren't monetized as much) but nobody knows since the algorithms are not transparent. If that's the case, it discourages users to license their videos this way and I think some articles on this suggest first uploading nonCCBY videos to first get popular before licensing any under CCBY. Please let me know if anybody has any sources/info on this. Prototyperspective (talk) 09:54, 28 June 2024 (UTC)

I clicked on a video from Commons a while ago that was supposedly CC Licensed and nothing showed uo for me. Maybe its a bug on their end or I just missed it though. --Adamant1 (talk) 10:01, 28 June 2024 (UTC)

Sometimes the license gets changed. CC-licensing can't be revoked but there are many cases where removal of that license should mean the video also needs to be deleted here...for example the video may contain nonCCBY clips that the uploader only became aware of later or the account was under control of somebody else. When uploading with V2C, there is an link to the archived site so one can check if it was CCBY at time of uploads and its adds a License review needed template so a user checks the current video (people don't seem to be doing this anymore). Prototyperspective (talk) 10:06, 28 June 2024 (UTC)

Yes, it annoys me a lot... But it depends on if you're logged in afaik. Anyway, you can retrieve the CC-BY note by looking into the website source code and by searching for "Creative Commons". This is where V2C gets his information from. It sucks and I assume there will be several deletion requests because of this misunderstanding --PantheraLeo1359531 😺 (talk) 18:24, 28 June 2024 (UTC)

I don't know how you access youtube but for me it's still displayed in the video description (after clicking "…more"). Prototyperspective (talk) 21:50, 2 July 2024 (UTC)

It's a new design that is currently being A-B-tested, I can confirm that the new design doesn't contain the CC license. Sjoerd de Bruin (talk) 22:32, 2 July 2024 (UTC)

Internet Archive versions of Youtube links since 2023 have been unable to load the full description to display the CC license. If we had more reviewers, or at least a bot to note the status, this issue would be more manageable. Joofjoof (talk) 23:05, 3 July 2024 (UTC)

Alternative Youtube frontends can be a solution to display status, as long as Youtube does not try to block them. Joofjoof (talk) 23:09, 3 July 2024 (UTC)

I can see the license (example). Maybe video2commons shouldn't add a link to the archive.ph archived site since it doesn't task it to actually archive it and the IA page seems to be sufficient. Prototyperspective (talk) 23:11, 3 July 2024 (UTC)

That's one of the reasons why I proposed a file verification feature in Commons last December, but it gained little support. MGeog2022 (talk) 10:29, 4 July 2024 (UTC)

It proposes to "Implement a mechanism to verify uploaded files" – I would think a technical mechanism would be better than having people manually review lots of files, in particular archiving the source page at upload. This is already done for uploads made via video2commons as described above, what about adding this to other uploads? (Another thing is that only the description needs to be archived, apparently IA even archives the video file itself for a while). There's so much things to do where people's time is needed so I think things like this shouldn't be added on top (especially since even currently there's not enough reviewers, I think nearly none of my V2C uploads have been checked so far) but rather there could be bots that do the opposite of this: flag (e.g. categorize) items as "Likely copyvios to review manually". Prototyperspective (talk) 10:57, 4 July 2024 (UTC)

Yes, probably the exact proposal could be better, and that's why it didn't receive many votes. I mean that I think that some kind of mechanism (better if it's automatic, of course) is needed to avoid losing content due to mistakes. There are many files in Commons, with very different quality levels, and randomly losing some of them is very sad, I think... this is as a kind of library, it's really sad to think that knowledge about some particular fact or document can be lost forever due to a change in YouTube's layout or similar seemingly minor reasons. Also think about the usage of images in Wikipedia: it's terrible to think that some decades from now, people may not be able to know how certain street of some relatively unknown city looked alike in 2001, because somebody stole a photo from Commons and uploaded it elsewhere under a non-free license, so it got deleted from here. I think these things are not being taken seriously enough. We have to think about next week's users first, but without neglecting those of 20 years from now. After all, Wikipedia was already there 20 years ago, and we continue to enjoy images that have been there ever since then, thanks to the fact that they have been preserved for all this time. MGeog2022 (talk) 12:17, 4 July 2024 (UTC)

+1 --PantheraLeo1359531 😺 (talk) 17:58, 4 July 2024 (UTC)

New York Public Library

Does anyone know what accession number we should be using for items from the Collections of the New York Public Library? -Broichmore (talk) 11:06, 28 June 2024 (UTC)

FWIW, just for one example, https://digitalcollections.nypl.org/items/225503f5-ae89-40e1-91e3-2f8cf6cc8297 gives three identifiers: RLIN/OCLC, NYPL catalog ID (B-number); and a UUID.

Our own File:Great Falls of the Potomac, from Robert N. Dennis collection of stereoscopic views.jpg gives three identifiers, but they don't seem to correspond to these in an obvious way: Catalog Call Number (which is clearly not a "B-number"), Record ID, and Digital ID.

https://archives.nypl.org/mus/24078#c1553136 gives IDs like "b. 164 f. 25" and "b. 110 f. 9-10"; it would not surprise me, though, if those were strictly IDs within the Lou Reed papers, and not in the NYPL collection as a whole, especially given the low numbers.

Looking at this, I'd be surprised if they have a single system that spans their entire archive.

@Broichmore: Have you considered contacting NYPL to see if they have a suggestion as to what we might use? - Jmabel ! talk 20:28, 28 June 2024 (UTC)

No, I haven't contacted them, as yet.

I suspect, that like the Library of Congress (LOC), this was one of the first GLAMs uploaded en-masse, consequently, it varies in the templates employed. So far, I've discovered that the accession number might be the NYPL catalog ID (B-number), think that's their shelf number.

There is a source template, I stumbled on, based on the image ID. Also a default sort based on that NYPL catalog ID (B-number) again. See image for an example. - Broichmore (talk) 21:18, 28 June 2024 (UTC)

Finding my own "published" content

Is there any way to do a sane query for files that I've uploaded (and/or for files where my account name occurs as part of the wikisource text on the file page) and where the {{Published}} template is on the talk page? - Jmabel ! talk 20:17, 28 June 2024 (UTC)

Still hoping for some ideas here. - Jmabel ! talk 19:19, 2 July 2024 (UTC)

Community Wishlist Survey is now Community Wishlist

Thank you everyone who has participated in the restructuring and rebranding conversations of the Wishlist so far.

Regarding the renaming, based on your feedback, we will keep the 'Community Wishlist' and remove 'Survey'.

Please read more about the renaming, check out the vote results and learn more about the re-opening of the Community Wishlist on July 15, 2024, in our latest update. –– STei (WMF) (talk) 20:20, 28 June 2024 (UTC)

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 need to upload a an AGPLv3-only file, but I have no experience with template creation (or even mimicking in this case; inspecting the source didn't help me much).

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 your upload (which I'll also do, though I'll change the license to the correct one once someone creates the template). --Veikk0.ma (talk) 23:58, 28 June 2024 (UTC)

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) 00:09, 29 June 2024 (UTC)

June 29

CfD for Category:History

I started a CfD to figure out the scope for Category:History. I'd appreciate as many comments as possible since the whole thing is a massive mess without an easy solution. Thanks. Commons:Categories for discussion/2024/06/Category:History Adamant1 (talk) 09:58, 29 June 2024 (UTC)

Identifiable employee

I'm curious about the image on the right: do we have a privacy guideline about photographs of employees in their workplace, without an indication that the employee has given their consent? I didn't find an answer in COM:IDENT, though maybe I missed something. Marnanel (talk) 11:39, 29 June 2024 (UTC)

This totally depends on the situation. In most cases I would say you can make and publish a photo of someone who is working if this would also be fine if the person would be there without working there. The given example that looks like someone hit the shutter button accidentally should definitely become deleted. GPSLeo (talk) 11:59, 29 June 2024 (UTC)

The flash was triggered, but may have been automatic. I tagged it {{Personality}}.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:10, 29 June 2024 (UTC)

I don't think there's enough there for definitive face recognition TBH. Broichmore (talk) 16:51, 29 June 2024 (UTC)

FWIW, doesn't look problematic to me. And no, it doesn't look like someone hit the shutter button accidentally. It does a good job of showing what it's like to have to carry a tray of drinks in a chaotic environment. - Jmabel ! talk 19:02, 29 June 2024 (UTC)

I suppose it's an interesting depiction, but the subject matter is mundane in the extreme, and this scene could easily be recreated at any place with anyone at any time, basically. Also, this image is technically of low-quality in a low-quality album, from a Flickr user of low-quality consumer-oriented point & shoot equipment.

Why even bother keeping this? If there's any question of personality rights or consent, why not delete it, and hold out for a properly-documented image of respectable quality? That would be so easy to obtain, whether it's candid or staged: simply obtain consent from the waitress and use high-quality equipment.

On enwiki we routinely reject low-quality images, and problematic or questionable images. It only makes sense to hold out for something that's really good, because, in the end, this is a very easy type of image to create. It doesn't depict a celebrity, an event, or anything special: just a night out drinking at a casino.

Apparently, the image is currently in use on exactly one article, on enwiki, regarding "complimentary drinks". The image itself really isn't connected to that particular topic at all: whether the waitress is charging for those drinks or not, we can't tell from the image itself. So I say, if we have any doubt of her consent to use this image according to Commons policies, let's delete it and hold out. Surely, some Commons user can go to Vegas this very weekend and make a dozen great photographs along with a signed model release? Elizium23 (talk) 02:16, 30 June 2024 (UTC)

There are hundreds of Wikiprojects. ENWP does not speak for all of them Trade (talk) 12:34, 30 June 2024 (UTC)

I doubt this would be ok in most of Europe. Enhancing999 (talk) 22:04, 29 June 2024 (UTC)

@Enhancing999: agreed. Do you have any reason to doubt that it is in Las Vegas (which is what it says in the description)? - Jmabel ! talk 02:03, 30 June 2024 (UTC)

The question was about that image, but didn't appear specifically limited to it, Las Vegas nor even the US. Enhancing999 (talk) 10:21, 30 June 2024 (UTC)

In terms of legality, it's probably legal. Casino-specific rules aside, the public areas of a restaurant or casino wouldn't bring with them a reasonable expectation of privacy. That said, this is a low quality image of someone which looks like it was taken surreptitiously while she was just doing her job. I don't know why someone would've uploaded this to Flickr. From the way it's used, I guess I understand why it was transferred to Commons (for a photo of a Vegas casino cocktail waitress), but there's probably a good case for COM:DIGNITY if not quality-based COM:SCOPE. Tough one, though. Courtesy ping to Belbury. — Rhododendrites ^talk |  21:00, 2 July 2024 (UTC)

Thanks, the context here was just that the en:Comps (casino) article needed an illustration and from memory this was literally the only image I could find on Flickr that conveyed the concept, it seemed better than nothing. Belbury (talk) 06:46, 3 July 2024 (UTC)

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)

June 30

Japanese figures/mask in trains

By using Google lens I find similar pictures (mostly with Japanese text and not out of the Commons) but not with any English explanation. I am looking for the correct category. Smiley.toerist (talk) 10:12, 30 June 2024 (UTC)

Category:Tengu masks. Omphalographer (talk) 21:23, 30 June 2024 (UTC)

How is this OK with Commons:Copyright rules by territory/Japan#Freedom of panorama? Yann (talk) 10:26, 1 July 2024 (UTC)

If this is considered artistic work. This is a traditional depiction of a Tengu. This is mass produced en put in several trains of the compagny. Mounting the mask on a board and mounting it in an unusual position on a train does not make it an art work. By the way: art work such as emblems etc on moving objects are usualy not protected. The figures in a carnaval procession can be freely photographed, while it is certainly the artistic work of (many) individuals. Can we photograph an individaul wearing an 'artistic' made mask?Smiley.toerist (talk) 09:22, 2 July 2024 (UTC)

PS: The railway compagny uses the mask in more places: File:Demachiyanagi station Tengu masks 20200602.jpgSmiley.toerist (talk) 09:31, 2 July 2024 (UTC)

@Smiley.toerist: by "unsual" do you mean "usual" or "unusual"? The words are opposites, and either is imaginable here. - Jmabel ! talk 19:03, 2 July 2024 (UTC)

unusual.

Someone had to come up with and design this particular version of a tengu mask and its composition. Posters are also mass-produced and mounted everywhere, but they are most of the time still copyrighted. Regarding art work on moving objects like masks: see COM:COSTUME. You may be free to photograph a lot of things, but keep in mind compatibility with derivative works. --HyperGaruda (talk) 19:47, 2 July 2024 (UTC)

Other figures in Japanese railways

wich figure? (also used on the outside: (File:Kawato station 2024 1.jpg)

Template for categories that only contain other categories

What is the name of the Template for categories that only contain other categories, and no images? I want to add it to Category:Vital records of the United States RAN (talk) 17:05, 30 June 2024 (UTC)

Are you thinking of {{CatCat}} or something else? - Jmabel ! talk 17:33, 30 June 2024 (UTC)

That is it, thanks! It looks like some above and below are using {{Categorise}}, they appear to give the same warning with different wording. --RAN (talk) 19:14, 30 June 2024 (UTC)

Similar but not identical. {{Categorise}} is a request that files be diffused out of a broad category (like, say, Category:History); having files in such a category isn't necessarily wrong but could be improved. {{CatCat}} is a stronger statement that a category should only contain other categories by definition (like Category:Categories!), so any files in that category are miscategorized and should be removed. Omphalographer (talk) 21:18, 30 June 2024 (UTC)

July 01

How do I request the speedy closure of a deletion nomination?

Hi. I have commented on the deletion nomination for an image of an Indonesian Government official. The original reason for the nomination was (in Spanish) "Who is it?". As far as I can figure out, simply not knowing who a person is, isn't a reason for a deletion nomination. So, I believe the nomination to be invalid, but can't find out how to get it reviewed and potentially shut down. In my opinion, it was possibly a bad faith nomination, because as soon as I categorised it (as it hadn't got any categories when uploaded), the nominator responded to say that he was "pleased to have drawn attention to the lack of categories" and would "thank me again when I added the correct ones". I'm not sure what to do with it. DaneGeld (talk) 12:38, 1 July 2024 (UTC)

@DaneGeld: Why haven't you linked it in the discussion here? If everyone is now in agreement that it should be kept, including the original nominator, then any experienced user (not just an admin) can close it as a speedy keep by clear consensus. - Jmabel ! talk 19:25, 1 July 2024 (UTC)

And ideally shouldn’t be closed by an involved user with the DR (other than the nominator). Bidgee (talk) 19:38, 1 July 2024 (UTC)

@Jmabel - I didn't link the discussion because I have fallen foul of being misconstrued as fishing for comments on discussions in the past, which is apparently frowned upon. I simply avoided it as I was asking for advice, rather than seeking others to comment on it. DaneGeld (talk) 21:48, 1 July 2024 (UTC)

@DaneGeld: in the future: state what you are wanting as neutrally as possible, and link the mention on VP or similar page from the discussion in question, so that you are clearly not doing anything surreptitious. - Jmabel ! talk 21:53, 1 July 2024 (UTC)

I've closed this nomination. Omphalographer (talk) 20:18, 1 July 2024 (UTC)

Thank you. DaneGeld (talk) 21:52, 1 July 2024 (UTC)

What's the best title for the category

Video game videos by name or Videos of video games by name--Trade (talk) 12:53, 1 July 2024 (UTC)

It seems like similar categories start with "videos", but "videos of video games" just sounds clunky. So who knows. --Adamant1 (talk) 12:58, 1 July 2024 (UTC)

I don't think you can get around repeating "video".

Also there is Commons:Categories for discussion/2024/04/Category:Video game videos. Enhancing999 (talk) 20:09, 1 July 2024 (UTC)

Another existing option is "Videos related to video games", which seems to be what the main category actually contains. "Video game videos" sounds like cutscenes and "Videos of video games" sounds like gameplay. Why "by name" and not "by game"? Sinigh (talk) 10:36, 2 July 2024 (UTC)

We already use by name for "Indie video games by name‎" and similar others so i assumed we needed to be consistent? Trade (talk) 15:01, 2 July 2024 (UTC)

Yes, but what I reckon is that "Indie video games by name‎" refers to the names of the indie games and, following the same logic, "Videos of video games by name" would then refer to the names of the videos rather than the names of the associated games. But I'm not sure, so take this with a grain of salt! Sinigh (talk) 16:24, 2 July 2024 (UTC)

Commons Gazette 2024-07

Currently, there are 184 sysops.

---

Edited by RZuo (talk).

---

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

--RZuo (talk) 21:23, 1 July 2024 (UTC)

Suppression d'un visuel

Bonjour,

Il y a plus de 11 ans, une personne a posté une photo de moi prise dans un cadre privé. Aujourd'hui, je souhaite vraiment qu'elle soit supprimée car elle peut me porter préjudice au travail. J'ai proposé sa suppression à plusieurs mais elle n'est jamais supprimée. Je ne sais plus quoi faire. Merci de m'aider. — Preceding unsigned comment added by Sayamelyay5 (talk • contribs) 21:34, 1 July 2024 (UTC)

@Sayamelyay5:

1. Is the picture in use on one of our sister projects, such as one of the Wikipedias?
2. Have you requested deletion as a personal courtesy or on some other basis?
3. You say the picture was the picture was taken in a private place. Was it with or without your consent?
4. Also, could you say what country, because issues about this vary widely from country to country.

Jmabel ! talk 21:56, 1 July 2024 (UTC)

Also, having looked slightly further into this: are you sure the picture in question has not already been deleted? Please check. - Jmabel ! talk 22:06, 1 July 2024 (UTC)

See Commons:Deletion requests/File:Sandrine Lefebvre-Reghay photo.png. I deleted the file in question as F10. Pi.1415926535 (talk) 22:11, 1 July 2024 (UTC)

Mille mercis. Y a t il un délai de suppression dans Google ? Bien à vous Sayamelyay5 (talk) 22:20, 1 July 2024 (UTC)

Bonsoir,

J'ai vérifié. Je la vois toujours sur Google en tapant mon nom.

Bien à vous Sayamelyay5 (talk) 22:19, 1 July 2024 (UTC)

Google takes some time to update its chache.

Anyway, the photo is no longer in Commons. If what Google shows is a problem, it should be dealt with Google. Pere prlpz (talk) 08:17, 3 July 2024 (UTC)

July 02

Acceptableness of having a source template also provide author information

Hello, {{Web source}} is a template for providing links to the sources of files uploaded from other places on the web. It currently has two (undocumented) parameters which are set up to provide author information, |author= and |photographer=. This seems a little odd to me because usually in templates like {{Information}} author and source information is listed separately instead of on the same line. For this reason, I am wondering if the current set up with {{Web source}} is inline with general Commons best practices and if it would be worthwhile to deprecate the parameters. For reference, the |photographer= parameter is currently only used about a dozen times and I haven't been able to find any uses of |author=. Thanks for any feedback and take care. —The Editor's Apprentice (Talk) 00:49, 2 July 2024 (UTC)

That's probably why they aren't documented. - Jmabel ! talk 03:25, 2 July 2024 (UTC)

The template was apparently thought primarily for artworks and to be used within template:artwork and similar templates and situations (although it can certainly be used in other contexts also). The template:artwork has a line "source/photographer", on the same line (which is somewhat strange and impractical, but it's been like that forever and unlikely to be changed easily). Therefore, it makes sense that template:web_source is compatible and includes relevant related parameters. I suppose that, in the line source/photographer of template:artwork, users may find practical to place the photographer inside the same template:web_source rather than outside it. Also, it must be noted that template:web_source is embedded in other templates, such as template:From_Google_Art_Project. Not sure about the parameter "author", but it might have a potential use in some such other circumstances. I would hesitate to just remove stuff from templates like that. Did you think of consulting the creator of the template (who is still active on Commons)? -- Asclepias (talk) 05:40, 2 July 2024 (UTC)

You're right, the |photographer= parameter does indeed mirror the set up of {{Artwork}}, so its not a complete anomaly and it would make sense for them to be compatible since they are often used together. I indeed share your hesitation to outright remove functionality from templates which is in part why I started this discussion. You're also right to ask about my consulting Zolo as the creator of the template. Usually in similar circumstances that is something I do, but since I was thinking about general best practices/acceptability, in this case I ended up going to a public forum first. That said, I would be interested in hearing about @Zolo's intentions and thought process, both for {{Web source}} as a whole and the |author= and |photographer= parameters in particular. Thanks to you both and please take care. —The Editor's Apprentice (Talk) 20:06, 2 July 2024 (UTC)

The template:artwork displays at the front end, "source/photographer", but not within the code, presumably photographer intended there is the scanner, and not the original photographer. Scanners in that sense exist for any and all GLAM products we have. These days we enter the url there, only a few years ago that might have, had to be the GLAM or an individual by name.

Interestingly |photographer= can be added into the artwork template, so I'll use it from here. Before I was putting that name under artist.

I'm probably doing this the wrong way, but for author I sometimes put in the author of the book the photo came from, or the full name of the artist/ photographer, whereas in artist I might put in the shortened signed name from the piece in question. Then sometimes I want to use the author field to put in the full unabbreviated name.

In any event, if the photo came, from say, en:Life (magazine), I would have; Life under the author, after all, they probably commissioned it, the photographer being a staffer.

I'm sorry, I wouldn’t use this template for anything. It's far too glib. Most of the photographs I upload come from GLAM's, and I use the {{Artwork}} template for them. The GLAM collection information being important here, especially the accession number. I really don't see why we would want to encourage glib uploading of any item, ignoring attribution, and this template, by its brevity, does exactly that.

We face an oncoming rush of AI derived images of epidemic proportions. The provenance and sourcing of where images come from, and their legitimacy is something we need to beef up, and I fear the project is asleep at the wheel on this issue. – Broichmore (talk) 11:25, 2 July 2024 (UTC)

Must admit. I'm getting tired of these author templates that takes up half my screen for no good reason other than to look fancy--Trade (talk) 15:06, 2 July 2024 (UTC)

Discussion on UAE copyright law before 1992

Hello. Kindly visit Commons talk:Copyright rules by territory/United Arab Emirates#‎UAE Copyright law before 1992 for the discussion. Regards, JWilz12345 (Talk|Contrib's.) 02:49, 2 July 2024 (UTC)

[Month] [Year] in [Place] - photos taken on, or photos of events that occurred

I have a question regarding categories [Month] [Year] in [Place], e.g. Category:June 2024 in Kraków. If there's a subcategory belonging to it, does it mean:

• Photos are be taken on [Month] [Year], or,
• Photos of the event that occurred on [Month] [Year]?

For example:

• Category:2024 Jagiellonian University pro-Palestinian campus occupation‎

Category contains photos taken on June 2024, but the occupation event started on May 2024. Apart of the Category:June 2024 in Kraków, should it belong to Category:May 2024 in Kraków then?

Dwxn (talk) 11:16, 2 July 2024 (UTC)

If a category like this belongs as a parent category of Category:2024 Jagiellonian University pro-Palestinian campus occupation‎, yes, I'd also include Category:May 2024 in Kraków. But my own feeling is that it should simply use Category:2024 events in Kraków, and the month-specific categories should be on individual photos. - Jmabel ! talk 19:10, 2 July 2024 (UTC)

Categories by day: date format?

Dates that clarify or disambiguate categories, such as categories for individual sports matches, should they be written as 6 October 2021 or 2021-10-06?

I would assume that the all-numeric format is the better option, since it automatically sorts similarly named categories by date, and since categories for specific days use that format (e.g. Category:2021-10-06). But both formats are in use and I haven't been able to find any instructions as to which one should be used in these cases.

Sinigh (talk) 11:38, 2 July 2024 (UTC)

In the HTML script stick with 2021-10-06 format. Broichmore (talk) 18:24, 2 July 2024 (UTC)

Yes, definitely! But what about the name of the category? Sinigh (talk) 18:33, 2 July 2024 (UTC)

If it's down to an individual day, I'd strongly favor ISO notation (2021-10-06 in this case). If it was just the month, then June 2021. - Jmabel ! talk 19:12, 2 July 2024 (UTC)

 Agree. I think both of those choices make the most sense for category trees. Sinigh (talk) 20:28, 2 July 2024 (UTC)

I've been using the format '2023-01 text' for categories where only the month matters (if not only the year). I think that is the most reasonable standard so that the cats are sorted chronologically on category pages. Prototyperspective (talk) 21:48, 2 July 2024 (UTC)

You can also solve that with a DEFAULTSORT. - Jmabel ! talk 22:45, 2 July 2024 (UTC)

I know but they are (more) unreliable and why not simply use this format putting the verbatim month into the title isn't useful and just causes problems due to people not adding a sortkey and the title longer. Prototyperspective (talk) 11:40, 4 July 2024 (UTC)

Yes, there are defaultsorting navigational templates for month categories. Sinigh (talk) 13:19, 3 July 2024 (UTC)

"both formats are in use"

where is "6 October 2021" systematically in use?

in any case, prefer yyyy-mm-dd over other formats. RZuo (talk) 16:33, 4 July 2024 (UTC)

Good question, I should have provided an example in my first post. I'm referring to categories like those you'll find in this one: Category:Women's association football matches in Sweden. In this particular case, there seems to be a preference for a comma followed by "M Month YYYY", but dates in brackets are not uncommon elsewhere. (This category also showcases the typically arbitrary mix of "vs", "v", and hyphens both with and without spaces, and not a single unspaced en dash to be seen.) Sinigh (talk) 18:39, 4 July 2024 (UTC)

Script for deletion sorting?

Is there a script/tool I can use to assist deletion sorting? I regularly come across DRs that should be categorized, or which were never updated with the result. There are a few such scripts on enwp, but deletion sorting works differently there. — Rhododendrites ^talk |  14:17, 2 July 2024 (UTC)

Template:Swiss Government Portrait

Could anyone proficient in German fix the dead link? --Trade (talk) 21:24, 2 July 2024 (UTC)

I am not proficient at all but I guess the links should be https://www.admin.ch/gov/de/start/bundesrat/geschichte-des-bundesrats/bundesraete-und-ihre-wahl/alle-bundesraete-liste.html and https://www.admin.ch/gov/de/start/bundeskanzlei/bundeskanzlerin/alle-bundeskanzler-liste.html. --Geohakkeri (talk) 05:53, 3 July 2024 (UTC)

July 03

We need someone to maintain CropTool

It would appear that CropTool is once again broken to the point of unusability. The person who got it working again in February 2024 did not take on responsibility to maintain it over time, which is of course their prerogative. We really need someone to maintain this quite valuable tool. - Jmabel ! talk 17:58, 3 July 2024 (UTC)

I hope this comes across without any challenging or derisive tone, Jmabel, but I have no idea what you're talking about. I've used CropTool hundreds of times and very rarely had any problems. I've used it in the past 48 hours. What kinds of issues are you experiencing? Is this a browser thing? —Justin (koavf)❤T☮C☺M☯ 18:10, 3 July 2024 (UTC)

@Koavf: A variety of issues, ranging from not getting it to load the image at all to going all through the process and not having it saved. I literally cannot remember the last time it worked for a rotate-and-crop (not counting a multiple of 90°), but it's been months. After half a dozen times in a row that it didn't work for me a couple of weeks ago, I've just switched to download, use GIMP, upload. We keep getting reports here and the VP (etc.) that it isn't working, and you are actually the first I've heard from in a month saying that is not a 100% experience; I'm actually a bit surprised to hear it is sometimes working. - Jmabel ! talk 20:12, 3 July 2024 (UTC)

I don't use it very often, but I've used CropTool a few hundred times in the last year and never noticed any issue. However, most times I don't rotate the image. Pere prlpz (talk) 20:34, 3 July 2024 (UTC)

For rotations, I just use a little tool to request User:Rotatebot make the change. —Justin (koavf)❤T☮C☺M☯ 21:13, 3 July 2024 (UTC)

Unless I'm mistaken, Rotatebot will only do multiples of 90°; it will not do (for example) a 1.27° rotation and corresponding crop, nor do I readily see how anyone could know that is exactly what they want without a visual tool. - Jmabel ! talk 22:25, 3 July 2024 (UTC)

It can do rotations down to 1 degree. From the tool I have:

If you request a rotation by 90, 180 or 270° Rotatebot will do this in a few hours. If you request a rotation by any other angle it will probably take longer.

So as long as you can translate whatever you want into 360 degrees, then you should be good. (I should also point out that I've never asked for a rotation other than 90/180/270.) Again, I don't want to downplay if you or anyone else is having problems, but between CropTool cropping and the RotateLink gadget, I don't see the immediate issues. Agreed that long-term maintenance is certainly highly important tho, as these tools will break somewhere down the line. —Justin (koavf)❤T☮C☺M☯ 22:36, 3 July 2024 (UTC)

For the record, I tried the CropTool again, since several people above said it was working. I started from a 4000 x 6000 px image already on Commons. The tool spent somewhere upwards of 30 seconds failing to fetch the image, then prompted me again for a URL. Repeated twice, at which point I'm comfortable in saying it is still broken for me. - Jmabel ! talk 03:34, 5 July 2024 (UTC)

Urgent: As Media of the Day predestined video with all white preview image

Hello, this is kind of urgent: The video File:Drone video of Keila waterfall and manor in Keila-Joa, Estonia.webm which is selected as Media of the Day for 8th of July, so in just 3 days (without the recent one I am writing this), does only display an all white preview image. Can do someone a fast repair? — Speravir – 23:07, 3 July 2024 (UTC)

Thanks for bringing this up, but there is a simple solution: we can choose a certain time as the frame that is the thumbnail. Input thumbtime= to make a different thumbnail. E.g. [[File:Drone video of Keila waterfall and manor in Keila-Joa, Estonia.webm|thumb|thumbtime=10]] looks like:

So we should be okay as long as someone chooses a good time for a thumbnail frame. —Justin (koavf)❤T☮C☺M☯ 23:34, 3 July 2024 (UTC)

Justin, I know, but this does not work for Media of the Day. I have forgotten to link to it above, but added this just now, or take a look from here: {{Motd/2024-07-08}} – yes, it is a template. — Speravir – 23:44, 3 July 2024 (UTC)

What do you think of this: https://commons.wikimedia.org/w/index.php?title=Template%3AMotd%2F2024-07-08&diff=891850543&oldid=890322763 —Justin (koavf)❤T☮C☺M☯ 23:49, 3 July 2024 (UTC)

Oh, and ! I think, this should be documented somewhere, {{Motd}} or {{Motd filename}} or both. By the way: Strange enough, even thumbtime=0 seems to work. — Speravir – 00:07, 4 July 2024 (UTC)

So, I consider this fast resolved. — Speravir – 00:07, 4 July 2024 (UTC)

@Koavf: Unfortunately your change broke the template, it seems. Wouldn’t Template:Motd/2024-07-08_thumbtime be the right way to handle this? --Geohakkeri (talk) 07:32, 4 July 2024 (UTC)

It's only broken on the language-agnostic version, not the translations. Template:Motd/2024-07-08 thumbtime does not display the actual media. Whatever solution others think works is fine by me. —Justin (koavf)❤T☮C☺M☯ 07:35, 4 July 2024 (UTC)

At least now it displays a reasonable title, even if it has an extraneous bit. —Justin (koavf)❤T☮C☺M☯ 07:37, 4 July 2024 (UTC)

And now it just looks correct on the template. Great work. —Justin (koavf)❤T☮C☺M☯ 08:07, 4 July 2024 (UTC)

Thanks. Templates can be quite tricky sometimes. --Geohakkeri (talk) 08:21, 4 July 2024 (UTC)

Thank you, Geohakkeri for the custom fix. It should in general, though, be available as template parameter. I do not have just gone into the deep details of it yet. — Speravir – 00:03, 5 July 2024 (UTC)

July 04

The Community Wishlist is reopening July 15, 2024

Here’s what to expect, and how to prepare.

Hello everyone, the new Community Wishlist (formerly Community Wishlist Survey) opens on 15 July for piloting. I will jump straight into an FAQ to help with some questions you may have:

Q: How long do I have to submit wishes?

A: As part of the changes, Wishlist will remain open. There is no deadline for wish submission.

Q: What is this ‘Focus Area’ thing?

A: The Foundation will identify patterns with wishes that share a collective problem and group them into areas known as ‘Focus Areas’. The grouping of wishes will begin in August 2024.

Q: At what point do we vote? Are we even still voting?

A: Contributors are encouraged to discuss and vote on Focus Areas to highlight the areas.

Q: How will this new system move wishes forward for addressing?

A: The Foundation, affiliates, and volunteer developers can adopt Focus Areas. The Wikimedia Foundation is committed to integrating Focus Areas into our Annual Planning for 2025-26.

Focus Areas align to hypotheses (specific projects, typically taking up to one quarter) and/or Key Results (broader projects taking up to one year).

Q: How do I submit a wish? Has anything changed about submissions?

A: Yes there are some changes. Please have a look at the guide.

I hope the FAQ helped. You can read more about the launch.

You are encouraged to start drafting your wishes at your pace. Please consult the guide as you do so. Also if you have an earlier unfulfilled wish that you want to re-submit, we are happy to assist you draft.

You can start your draft (see an example) and don't hesitate to ask for support when drafting by sending me a link to your draft/sandbox via Meta email to help/review it. Alternatively you can leave the link in the Drafts List. –– STei (WMF) (talk) 14:36, 4 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)