Commons:Village pump/Proposals

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

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

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

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

Please note

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

 

Start a new discussion

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

Increase of file size limit on Commons for future-proof purposes

Hey folks!

The current file size limit is 4 GiB (approx. 4.3 Gigabytes), see COM:MAXSIZE. I want to propose a increased file size limit. The limit was increased in April 2016 from 2 to 4 GiB.

Since then, the sizes of files increased over time due to larger video resolutions.

I want to give some examples when files exceed the 4 GiB threshold:

• 4K YouTube videos after 25-35 minutes
• FHD DSLR/DSLM videos 8-15 minutes
• 4K DSLR/DSLM videos after 2.5-8 minutes
• 8K DSLR/DSLM videos after 1.25-4 minutes

Videos for example exceed the size limit of 4 GiB quite fast, but also high-resolution scans of 3D objects from organizations like the Smithsonian Institution may offer files that are larger than the limit (and where file splitting is very problematic). I have a large aerial image of Munich that is also too large right now, but offers many details. Over time, more and more files will come into conflict with this limit, as cameras etc. will become more capable. I would like to propose an increase to 32 or 64 GiB if possible. When colored meshes on Commons will be available, a higher file size limit would also be very appreciated.

What do you think?

Greetings and thank you a lot, --PantheraLeo1359531 😺 (talk) 17:17, 9 October 2023 (UTC)

This has already been requested multiple times, but till now the WMF team did not work on a solution for the current technical limitations.

Tracked in Phabricator
Task T191802

GPSLeo (talk) 18:19, 9 October 2023 (UTC)

Thank you for mentioning, I hope this issue will be served soon :) --PantheraLeo1359531 😺 (talk) 20:21, 9 October 2023 (UTC)

 Comment It was recently made possible to upload files up to 5 GB. I don't know when this will be live. See phab:T191805. Yann (talk) 17:29, 2 November 2023 (UTC)

While the filesize is likely to increase a bit in the short term (year?) to 5GB (as mentioned by yann), a further rise is very unlikely to happen any time soon. Reasons:

1. It costs a TON of money. Big file handling is expensive. Much more expensive than text. Not just in storage (originals, backups), but also in network cost (all files have to be moved over the internal network), hardware costs (plain server capacity). There is currently 440TB of originals, 22TB of original video. And then a not exactly known amount of derivatives of those originals (thumbnails and smaller versions of the big videos). In many ways, video is already creating a 'disproportionate' impact, compared to how much it is used by the users.

2. Anything over 5MB basically cannot be send to a browser. Therefore you need to thumbnail, postprocess etc. So CPU, and yet more datastorage to store the results of that. Specifically in the above example you are speaking about things like 8K, that not even Youtube is doing (publicly). And that is for a good reason. Handling such big files essentially requires purpose designed hardware to do the decoding and encoding (GPU, or like Youtube, who design and manufacture their own hardware for this). It cannot really be done with the generic compute power that we have available within Wikimedia. I advise watching this video by LTT, where they comment on last year's Youtube experiment of charging for 4K. LTT runs their own video website called https://www.floatplane.com so they have some experience with the cost of high res video.

3. Media handling is unresourced by WMF. As in, there are 0 engineers dedicated to improving and modernizing the multimedia stack. The only effort spend is on keeping the current multimedia stack alive.

4. It is pretty hard to be AND wordpress AND the internet archive AND youtube AND thingiverse AND Wolfram Alpha on a shoestring budget. Wikimedia always has been 10+ years behind these websites and is likely to remain so. We can't scale like them, because we don't have a narrow focus, and because expertise at the bleeding edge is very expensive. Just waiting 10 years is the affordable way to get there.

5. The entire infrastructure for filestorage currently has a 5GB limit. Files above that size cannot be addressed, without major re-architecting of the storage layer used by Wikimedia. This rearchitecturing is unlikely to happen due to the earlier mentioned points.

The best solution for this is still to host these on a separate archive site, and upload a smaller more websuitable version to Commons. —TheDJ (talk • contribs) 19:54, 2 November 2023 (UTC)

Thank you very much for giving insights into this issue! The 5 GiB limit is a good thing to hear! Maybe we get a solution some time that is a compromise between resources and upload limits :) --PantheraLeo1359531 😺 (talk) 18:27, 4 November 2023 (UTC)

Otherwise we have to ask Google for server (technology) support ;D --PantheraLeo1359531 😺 (talk) 18:31, 4 November 2023 (UTC)

TheDJ, thanks from me, too, for your insightful statement. It continues to frustrate me that the WMF, with its heaps of donator money to spend, is allocating so few resources and investment to Commons. In my view, "In many ways, video is already creating a 'disproportionate' impact, compared to how much it is used by the users" is just one side of the coin: The very poor support of video on Commons isn't encouraging use - but it could be very valuable and an alternative to increasingly heavily commercialized platforms such as YouTube (which is now starting banning adblockers). Commons is the only truly free media platform where users don't pay with their personal data or with money for use, and I think it needs strengthening. The WMF has the money, more than enough, it's only a matter of willingness. A "shoestring budget" is not an inevitability - it's well known that the WMF's assets have risen each year by many millions. I certainly would not ask Google for any technology support, though, as I think this is one of the corporations we should distance us from. Gestumblindi (talk) 10:26, 9 November 2023 (UTC)

Millions is still a shoestring when it comes to video. This is another example of people having no idea how much organisations like Google spend on stuff like this. Start thinking in billions. —TheDJ (talk • contribs) 11:49, 9 November 2023 (UTC)

Compare with w:Vimeo. Half a billion revenue and still 80 million of losses in a year. So we'd need almost 600 million of donations a year to do what they do. And it's the only thing they do, they don't have to worry about anything but video. —TheDJ (talk • contribs) 11:56, 9 November 2023 (UTC)

Well, I would be happy with a far more limited offering than YouTube or Vimeo have, I don't think we need 4K or even 8K; all I ask for is a reasonably smooth upload and use of medium-sized, medium-quality video (I think Full HD - 1080p - shouldn't be too much to ask?), and we don't have even that, it's all very rickety. Gestumblindi (talk) 19:24, 9 November 2023 (UTC)

Personally, I think 5 GiB is enough for Commons. Our purpose is education, not entertainment. We don't need 8K videos to explain how mitochondria work. 480p works fine. 1080p is probably overkill. And 4320p (8K) is just totally unnecessary. What we need is better quality video content, not better video resolution. Nosferattus (talk) 16:46, 9 November 2023 (UTC)

Take a good look at 480p versus 1080p, say https://upload.wikimedia.org/wikipedia/commons/thumb/0/00/Grand_bassin_octogonal_Jardin_des_Tuileries_003.jpg/640px-Grand_bassin_octogonal_Jardin_des_Tuileries_003.jpg (428p) versus https://upload.wikimedia.org/wikipedia/commons/thumb/0/00/Grand_bassin_octogonal_Jardin_des_Tuileries_003.jpg/1280px-Grand_bassin_octogonal_Jardin_des_Tuileries_003.jpg (857p) versus https://upload.wikimedia.org/wikipedia/commons/0/00/Grand_bassin_octogonal_Jardin_des_Tuileries_003.jpg (2755p) File:Grand bassin octogonal Jardin des Tuileries 003.jpg. There's a smudge in the top middle in 428p that turns out to be a bird. Even going to 857p makes it much easier to see the details of the Ferris wheel and the people and the statues. If you want to stick with mitochodria, compare https://upload.wikimedia.org/wikipedia/commons/c/cf/Aging_Phenotype_by_mtDNA_Mutation_in_mice_Edgar_et_al._2009.png (1027p) to https://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Aging_Phenotype_by_mtDNA_Mutation_in_mice_Edgar_et_al._2009.png/528px-Aging_Phenotype_by_mtDNA_Mutation_in_mice_Edgar_et_al._2009.png (480p), where text and details are nigh illegible. File:Aging Phenotype by mtDNA Mutation in mice Edgar et al. 2009.png --Prosfilaes (talk) 17:22, 9 November 2023 (UTC)

I think it depends on the video content how important resolution is. For simple animations, FHD is certainly enough. For historical (modern) events for example, 4K or even 8K is probably really appreciated, for documentation purposes. --PantheraLeo1359531 😺 (talk) 19:31, 12 November 2023 (UTC)

Addition: Is 8K unnecessary? Not always. 8K first of all allows cropping to distinct areas in the video. And let's take a video of a collapsing building, recorded in 8K, we can extract single images with a resolution of many full-frame cameras. If we take pictures from YouTube in Full HD, we usually have a quite low level of detail. --PantheraLeo1359531 😺 (talk) 19:38, 12 November 2023 (UTC)

Total size of uploads

Once we are here, is the total size (of uploads smaller that 5Gb) a problem? Are we safe for the time being, or is there a chance that WMF soon will not be able to host the entire volume of the files (say photos, not videos) which significantly grows every day?--Ymblanter (talk) 21:12, 9 November 2023 (UTC)

In my opinion, I see no problem regarding hosting. Right now we have at least ca. 480 TB. It is common that modern datacenters have 1.5 petabyte or more. With a yearly growth of ca. 80 TB in 2022, it will take time until Commons hits this threshold. I could also imagine WMF has some reserves, even if the data amount grows even faster. 1 Petabyte could be reached with 50x 20 TB hard disk drives. Probably, the used disks are smaller in capacity. If Commons will acquire several terabytes at once, this could be challenging, but I assume that we're save. --PantheraLeo1359531 😺 (talk) 19:35, 12 November 2023 (UTC)

Thanks, makes sense to me. Ymblanter (talk) 18:29, 15 November 2023 (UTC)

Flickr has database which vastly greater than Commons and I see no problem with it. Юрий Д.К 06:35, 15 November 2023 (UTC)

But Flickr, after it was bought by SmugMug, decided that it can not keep expanding, that the database was already too big, and users must pay if they want to be above the (pretty moderate) limit. Ymblanter (talk) 18:29, 15 November 2023 (UTC)

According to this website, flickr has 10 billion images. We are far away from that :) --PantheraLeo1359531 😺 (talk) 19:19, 20 November 2023 (UTC)

Even more than that — according to the Flickr Foundation presentation at GLAMWiki last week, it's more like 50 billion! Sam Wilson 00:14, 21 November 2023 (UTC)

That's really a lot --PantheraLeo1359531 😺 (talk) 17:56, 23 November 2023 (UTC)

If I'm interpreting [1] right, i think we are currently at 821TiB (presumably one of those lines is Eqiad data center and the other is codfw, but I'm just guessing). Presumably there might be multiple copies of media stored to guard against hardware failure. Generally I would suggest not worrying about server capacity as long as you are doing something useful to the mission unless someone from the WMF SRE team specifically says to worry. After all, the reason we have servers is so they are used. Bawolff (talk) 04:02, 24 November 2023 (UTC)

I'm not so worried about storage space myself, but the upload wizard doesn't seem to be very reliable and I don't think people should be able to upload extremely large files until there's at least a way to resume uploads. Otherwise there's really no point. If I can't even upload a 200mb image as someone with fast cable internet because it just times out then there's really no point though. --Adamant1 (talk) 04:10, 24 November 2023 (UTC)

@Adamant1: I suggest you try using User:Rillke/bigChunkedUpload.js (doc at User talk:Rillke/bigChunkedUpload.js and help at Help:Chunked upload).   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 13:20, 25 November 2023 (UTC)

Thanks for the suggestion. I'll have to do that. --Adamant1 (talk) 13:39, 25 November 2023 (UTC)

@Adamant1: You're welcome, but you forgot to ping me.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 13:42, 25 November 2023 (UTC)

image-reviewer → license-reviewer

Hi. I propose to change the technical name of the license reviewer user group from image-reviewer to license-reviewer. This will make it in consistent with the group's real name, and also in general everyone uses the term "license reviewer" and not "image reviewer", and it is correct too, as the group members review all type of files and not just images. I see no reason why this shouldn't be done. We'll have to do following things for this:

• Request on Phabricator for technical stuff (config, WikimediaMessages, migration...)
• Update abuse filtes
• Update MediaWiki pages (includes Gadgets)
• Update user scripts if any
• Update required Commons, Template, Help pages (like COM:LR)

Please point out other things if any. Thanks! -- CptViraj (talk) 05:13, 2 November 2023 (UTC)

Discussion

I do not think this is a problem. The technical term for Admins is sysop and for Oversighters it is suppress. But if we do a change here we should also consider the proposal I made some month ago (Should we simplify user rights?) to remove the dedicated rollback right and give this right to all patrollers and license reviewers. GPSLeo (talk) 15:27, 2 November 2023 (UTC)

I personally dislike sysop for admins as it is no longer relevant and can be confused with system administrators but it is a MediaWiki core setting so a big mess and not in our hands, while the license reviewer is a local Commons group, so it makes sense to keep it consistent and updated, and it is in our hands so easy to manipulate. For the proposal you linked, I personally agree with Mdaniels5757 there. For now, I'd say let's please keep that seperate as then this proposal will be wider in scope then it's original non-controversial (?) subject. -- CptViraj (talk) 17:26, 2 November 2023 (UTC)

Not to say I'm against the idea, but don't you think "license-reviewer" is to close in wording (if not purpose) to the Volunteer Response Team or that there is a chance people will mix them up? --Adamant1 (talk) 20:10, 2 November 2023 (UTC)

Well, non/new users have always confused them and will continue to do so. But I have never seem them calling it image reviewer, as our help and project pages use the term license reviewer and established users also use the latter term in general except while talking in technical way, so I believe it won't make a much difference for them. Even if they are using/reading/understanding the former term then it could be misleading for them as it suggests that the group members review only images but that's not the case, they can also get confused believing license-reviewer and image-reviewer are two different user groups, so I think it makes sense to change it and make it consistent. And for us, established contributors, who understand workings, It was license reviewer with VRT access or without VRT access, and will remain the same. -- CptViraj (talk) 09:13, 3 November 2023 (UTC)

@CptViraj: Wouldn't that be solved by calling it "file reviewer" then? I don't think just because "image" doesn't work that it necessarily means "license" does. --Adamant1 (talk) 20:33, 4 November 2023 (UTC)

@Adamant1: The sole role of the user group is to review licenses, and that's what it makes different from patrollers, otherwise files can be reviewed by patrollers, too. So I believe 'file reviewer' could cause confusion. Also 'license reviewer' has become a common name now, changing it completely won't be a good idea IMHO. -- CptViraj (talk) 21:12, 4 November 2023 (UTC)

That makes sense. Thanks for clarifying it. --Adamant1 (talk) 16:08, 6 November 2023 (UTC)

•  Support OK for me. Yann (talk) 17:28, 2 November 2023 (UTC)
•  Support OK for me, too.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 09:57, 6 November 2023 (UTC)
•  Support --Adamant1 (talk) 16:08, 6 November 2023 (UTC)
•  Weak oppose I do not see the need for the change of this internal parameter. A change could break a lot of (unmaintained) tools. --GPSLeo (talk) 16:10, 6 November 2023 (UTC)
•  Support Killarnee (talk) 06:22, 7 November 2023 (UTC)
•  Support it is never too late to implement the changes required. Thanks --C1K98V ^{(💬 ✒️ 📂)} 06:35, 7 November 2023 (UTC)
•  Oppose per GPSLeo. It's a purely cosmetic change that has the potential to break things. Commons is already struggling under backlogs basically everywhere; if we lose a tool or two it'll only get worse. The Squirrel Conspiracy (talk) 10:42, 7 November 2023 (UTC)
•  Weak oppose I would support a change, provided the concerns by GPSLeo and The Squirrel Conspiracy are addressed. We are risking here that tools are not updated accordingly and would need to know beforehand what could possibly break and who is ready to fix it. Filter 70 would have to be updated as well. --AFBorchert (talk) 15:57, 7 November 2023 (UTC)
• In the proposal itself, I have already listed the on-wiki things (including the AF above) that will need updating. If anyone know any other gadgets/tools/scripts/etc.. please help list them, leftovers can be fixed. I'll be happy to update the things that I could, will surely appreciate more hands. A cosmetic change but IMO we shouldn't be afraid to do them when it is possible without causing heavy disruption, this isn't going to shut the site, the group has been renamed before. This isn't gonna get implemented overnight, discussion is likely going to be open for several months, all the replacement points can be found out, and if passed, we can do it with proper planning, thus minimising the chances of breaking things but I cannot guarantee 100% smooth transition, after all these things is a process of continual refinement. -- CptViraj (talk) 19:19, 8 November 2023 (UTC)
•  Support --Ooligan (talk) 20:10, 8 November 2023 (UTC)
•  Weak oppose I don't see a large benefit and it could potentially break unmaintained tools. The previous renaming to fix the capitalization seems like it was a lot of work to coordinate. Apparently fawiki also uses this user group, so it would need to be coordinated with that wiki as well. Frankly, it doesn't seem like it's worth all the effort. Nosferattus (talk) 16:16, 9 November 2023 (UTC)

  Hi. The work you see on phab is on system administrator/patch uploader's side (could be volunteer or staff), I'm sure they won't refuse to help and implement if there is consensus, some of it was done with maintenance scripts (semi-automatic), some of it won't be required as they were one-time fixes, if you see the dates, you can see that most of it was done on the same day. The previous rename was an uncontroversial maintenance change done by the sysadmins themselves to make the user groups in line with others, it included both fawiki's group as it required fix too but that's not a case here. The fawiki user group has nothing to do with ours, both are independent from each other. -- CptViraj (talk) 19:36, 9 November 2023 (UTC)

Null edit to avoid auto-archiving. -- CptViraj (talk) 17:38, 8 December 2023 (UTC)

Restrict webp upload？

https://commons.wikimedia.org/w/index.php?sort=create_timestamp_desc&search=filemime%3Awebp

i suggest restricting upload of webp files to autopatrol users (like mp3), because very often webp uploads are copyvio taken from the internet or previews of svg logos. RZuo (talk) 14:07, 22 November 2023 (UTC)

•  Support Currently I would say 90% of WEBP files are copyright violations. Yann (talk) 15:19, 22 November 2023 (UTC)
•  Support.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 15:30, 22 November 2023 (UTC)
•  Support The vast majority of webp files uploaded here are copyvios. Exceptions for individual users are easy to add to an edit filter. Pi.1415926535 (talk) 20:05, 22 November 2023 (UTC)
•  Support.--Vulcan❯❯❯Sphere! 08:23, 23 November 2023 (UTC)
•  Support Per Pi.1415926535. --Adamant1 (talk) 08:28, 23 November 2023 (UTC)
•  Support Seems ok to me. If we ever run into real problems with such a policy we can modify it. --Rosenzweig τ 08:53, 23 November 2023 (UTC)
•  Support I wonder why we still have no such restriction. Юрий Д.К 11:56, 23 November 2023 (UTC)
•  Support A lot of WEBP files I see when I check files are copyvios. Abzeronow (talk) 16:09, 23 November 2023 (UTC)
•  Support I don't see how this could go wrong; this would definitely reduce copyright violations. 20 upper 08:07, 25 November 2023 (UTC)
•  Support per Yann's claim. I want to encourage good uploads, but Commons must also guard against copyvios. Recent proposals have an appropriate aim of reducing copyvios and patrolers' workload. The balance here favors restriction. Glrx (talk) 18:56, 25 November 2023 (UTC)

 Strong support second in motion to @Yann, Abzeronow, and Glrx: et.al.. Examples of my autogenerated messages of WEBP copyvios: this, this, and this. And I can still remember the very first WEBP file I encountered here, which is a copyvio itself! Commons:Deletion requests/File:Beijing Skyline.webp. JWilz12345 (Talk|Contrib's.) 08:17, 26 November 2023 (UTC)

•  Support Would reduce copyvios for sure; I'm not sure the proportion is as high as some have mentioned based on spot checking, but I usually check the ones that look obvious so it's not exactly a random sample. Gnomingstuff (talk) 23:05, 29 November 2023 (UTC)
•  Oppose I think in general, discriminating on filetype is a bad direction (same with mp3). It further complicates and obfuscates the upload process and doesn't stop copyright violations, it stops contributors. Most of these can easily be spotted by filtering the upload list on new contributors. Or we can just ban SVGs as well, because most logos are copyvios. —TheDJ (talk • contribs) 18:46, 30 November 2023 (UTC)

  If we would have enough people checking the unpatrolled uploads we would not need such filters. Unfortunately we do not have enough people checking uploads and edits and therefore need tools to reduce the workload. GPSLeo (talk) 19:31, 30 November 2023 (UTC)

  I think that creating these kinds of non-transparent and highly confusing roadbumps is part of the reason WHY we don't have enough people. That's my point. And I note that just two posts below this we already have someone getting tripped up with the SVG translator software because of a similar rule #File overwriting filter blocks SVG Translate. It's one of those 'a small cut doesn't seem so bad, until they are a thousand cuts"-kind of problems. Considering how much ppl complain about UploadWizard, stuff like this isn't helping lower the barrier to entry either. —TheDJ (talk • contribs) 11:07, 9 December 2023 (UTC)

  Plus we could just make patrolling itself easier by having uploads sorted per date, a single patroller can simple take a few minutes to patrol all new ".webm" files. Do this for every file type and we don't need to exclude people from uploading. If a patroller only wants to patrol videos, sounds, PDF's, Etc. they now have to go through all uploads, but by making it easy to filter out and making these pages easily accessible to everyone and transparent (like OgreBot's Uploads by new users) we could easily patrol everything with fewer people. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:55, 9 December 2023 (UTC)

 Support. Very few cameras or image editing tools output WebP images; when one is uploaded, it's almost always because it was downloaded from a web site which automatically converts images to that format for display (and, thus, is very likely to be a copyright violation). We already have abuse filters which block other types of uploads from new users which are overwhelmingly likely to be problematic, like MP3 files (Special:AbuseFilter/192), PDFs (Special:AbuseFilter/281), and small JPEGs (Special:AbuseFilter/156). Omphalographer (talk) 04:25, 3 December 2023 (UTC)

•  Oppose, per TheDJ. Additionally, this would exclude a lot of people who contribute to other Wikimedia websites but aren't necessarily active here, a user could be a trusted user, an admin, or a prolific contributor, Etc. on another Wikimedia website and "a noob" at the Wikimedia Commons. They could have good knowledge of how video files work and which ones are and aren't free, but they will find that they can't upload anything here. If we keep making the Wikimedia Commons more exclusive we will fail at our core mission to be for all Wikimedians. If new users are more likely to have bad uploads then we should have a page like "Commons:Uploads by unpatrolled users by filetype/.webm/2023/12/09" (which includes all users who aren't auto-patrolled), this will simply exclude too many people. We can't know which people and uploads we exclude because a user with a free video file will come here, attempt to upload, see "You have insufficient privileges for this action", and then never return (without ever telling anyone what (s)he wanted to upload and why they didn't). "Anyone can contribute to" is the core of every Wikimedia website, the moment you compromise this you lose whatever made this place Wikimedia. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:49, 9 December 2023 (UTC)

Deprecate PD-US

There have been discussions about this every now and then on the template talk page, but they haven't generated any sort of clear consensus due to lack of consensus, so I'll ask the community here.

This template is overly broad. There are more specific templates avaliable (Category:PD US license tags), and it is always better to use a more specific PD template over this. Furthermore, having a very broad template would encourage copyright mistakes ("this would probably be PD"). Therefore, it should be deprecated and put on some kind of backlog. —MATRIX! {user - talk? - useless contributions} 21:26, 22 November 2023 (UTC)

EDIT: It seems I have been a bit unclear on what deprecate means. I mean that we should add a custom non-transcluded edit notice to the top discouraging use (something like {{Deprecated}}).

•  Oppose This is still useful, when we know there is either no notice or no renewal. BTW this is used on 4,209,007 files. What do you propose to do with these? Yann (talk) 21:53, 22 November 2023 (UTC)

  @Yann: I say that we should not outright remove it for obvious reasons, but deprecate it and discourage its use. —MATRIX! {user - talk? - useless contributions} 18:20, 23 November 2023 (UTC)

•  Oppose This is valid for pre-1923/24/25, etc. works. Just because something else exists doesn't mean this is inadequate. If anything, I'd propose getting rid of all the federal government tags we have, as it's irrelevant which agency or office published it. —Justin (koavf)❤T☮C☺M☯ 01:49, 23 November 2023 (UTC)

  @Koavf: The issue is this could mean {{PD-USGov}}, or {{PD-US-expired}}, or {{PD-US-no notice}}, etc etc. It is overly broad. {{PD}} was deprecated for the same reason. Saying "this is PD in the US" is quite a broad statement, this template doesn't really provide a clear rationale. —MATRIX! {user - talk? - useless contributions} 18:22, 23 November 2023 (UTC)

  Something could be in the public domain for all three of those reasons. You have a sensible "deprecate and discourage" proposal above which I could get behind, but is it really the best use of our time to go thru these millions of files? —Justin (koavf)❤T☮C☺M☯ 20:39, 23 November 2023 (UTC)

  @Koavf: I have struck out the "and put on some kind of backlog" part after seeing the number of files this template is transcluded to. I don't think anyone is going to manually sort millions of files. —MATRIX! {user - talk? - useless contributions} 21:39, 23 November 2023 (UTC)

•  Oppose There are situations where we know a work is PD, but not the precise sub-reason. Or can be used by bulk uploaders on a batch of known-PD files where it would be onerous to figure out the reason file by file. Of course one of the others should be used if known, but it doesn't make this one invalid. The precise reason is not always relevant in other countries anyways (the lifetime of the author often is, even though irrelevant in the US), so the extra precision isn't always too helpful. And many countries have catch-all tags rather than split-out ones. If we want to add a note that a more specific tag is preferred, that'd be fine. Carl Lindberg (talk) 13:48, 23 November 2023 (UTC)

  "There are situations where we know a work is PD, but not the precise sub-reason" what do you mean? If it's before 1928 it's probably {{PD-US-expired}}. If it's 1928-1963 it's probably {{PD-US-not renewed}} etc etc. If anything, not providing a specific tag encourages copyright mistakes. —MATRIX! {user - talk? - useless contributions} 18:26, 23 November 2023 (UTC)

  Yes. You don't always know a date. Maybe you just know it's before some particular date, and therefore know it wasn't renewed, but it could be expired, no-notice or not-renewed. Or you don't know exactly when it was published. If you have full information, sure use a more specific tag, but you don't always have that full information. Carl Lindberg (talk) 19:04, 24 November 2023 (UTC)

• {{O}} per Carl, Yann, and Justin.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 14:54, 23 November 2023 (UTC)
•  Support deprecation as better explained, this won't impede mass imports. I struck out my previous opinion.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 20:14, 23 November 2023 (UTC)
•  Comment User:DPLA bot tags hundreds of thousands of uploads with {{PD-US}}, presumably because Dominic is going on the DPLA's assurance that the materials are in the public domain, and the DPLA in turn is relying on libraries' assurance, and no one "upstream" of us is making any distinction as to why these materials are in the public domain. - Jmabel ! talk 22:40, 23 November 2023 (UTC)
•  Comment It might be worthwhile to put a notice at the bottom that says "This license should not be used if a more specific license is valid." The Squirrel Conspiracy (talk) 02:01, 24 November 2023 (UTC)

• Definitely support adding something to that effect. Carl Lindberg (talk) 19:06, 24 November 2023 (UTC)
• I also support such a mention. Yann (talk) 09:39, 26 November 2023 (UTC)

•  Support Although it's kind of pointless if the template is being automatically added to files by the DPLA bot. But conversely, there should really be more of an effort on the DPLAs end to use more specific licenses when they can anyway per The Squirrel Conspiracy. Or at least on the bots/Dominics end if the DPLA doesn't want to do it themselves for whatever reason. --Adamant1 (talk) 08:56, 26 November 2023 (UTC)

•  Support Deprecate for future uses. It should always be possible to be more specific. {{PD-old}}, a similarly broad and unspecific tag, is already marked as deprecated ("PD-old is a deprecated generic template which should not be used for new uploads"). Gestumblindi (talk) 12:47, 26 November 2023 (UTC)
  • It is not always possible to be more specific. PD-old had a single direct replacement (and there is nothing preventing its use actually; the "deprecation" is only in its documentation). I would certainly support discouraging use of PD-US when one or more of the other specific tags can be used, which should be most cases, but I can't support altogether banning its future use. We certainly aren't going to fix the millions of existing uses. PD-US is still very useful for bulk uploaders, and in certain situations where we don't have full date knowledge, but enough to know it's PD beyond a significant doubt. I haven't needed to use it often, but I'm pretty sure I have a handful of times. The documentation does say If at all possible, please use a more specific tag so that aspect is covered in the documentation, though adding a similar note to the actual template may be a good idea. I think the tag has been removed from the upload tools as an easy option, which is also good. "Deprecating" in the style of PD-old, which is mainly just wording in the documentation, may be fine (though there are still valid uses, so it would only be deprecated when a more specific template can be used). Not sure that adding any non-transcluded element to the top is much different than the wording in the documentation really, though it could be made a little bit stronger. Carl Lindberg (talk) 15:57, 26 November 2023 (UTC)

Disabling talk pages of deletion requests

While there now exists Template:Editnotices/Group/Commons talk:Deletion requests that notifies users to make comments on the deletion request pages themselves, it is evidently ignored, as seen in 54conphotos' comments on the talk page of Commons:Deletion requests/File:KORWARM2.jpg (which I transferred to the main page and in Amustard's comment on a Turkmen deletion request which I subsequently transferred to the mainspace. As it is very evident that the edit notice is being ignored, I am proposing that the "Talk" namespace be disabled in all pages with prefix "Commons:Deletion requests/". This should be a permanent solution to the incidents that should have been better avoided. For existing talk pages of deletion requests with comments, the comments (including mine if ever I had responded to uploaders in the talk page namespaces) should be transferred to the deletion requests mainspaces, with consideration to the dates of the comments or inputs. JWilz12345 (Talk|Contrib's.) 09:10, 26 November 2023 (UTC)

 Support At least, the use of DR talk pages should restricted to power users (admins, license reviewers?). Yann (talk) 09:37, 26 November 2023 (UTC)

@Yann that may be OK. Restricted to admins and license reviewers. Or the talk pages are still existing visually but those who don't have user rights, even autopatrolled ones, will be barred from editing talk pages and be presented with a boilerplate notice that they don't have the right to edit talk pages and should instead comment on the main discussion page, with a link to the DR itself in the notice (do not expect several new users to comprehend what they are reading in the notices). JWilz12345 (Talk|Contrib's.) 10:09, 26 November 2023 (UTC)

 Support --Krd 11:23, 26 November 2023 (UTC)

 Support Christian Ferrer ^(talk) 11:56, 26 November 2023 (UTC)

Thank you for pointing out this Template:Editnotices/Group/Commons talk:Deletion requests location in Wikimedia. This was not ignored as you said in your comment, it simply was no where to be found at the time I commented. It's a shame it's too late to place a comment there as I would have done so. Even your notes to me are very confusing as the names of Comments pages do not match up so I can find them as are all the previous notes received by others. Being new to this platform, I have found it very confusing to find things that are suggested when seeing comments by others.

Hopefully I will have the hours to research and better understanding of the workings of Wikimedia Commons in the future. Thanks again! 54conphotos (talk) 13:32, 26 November 2023 (UTC)

 Support or, if it's easier, systematically turn them into redirects to the relevant project page. - Jmabel ! talk 21:56, 26 November 2023 (UTC)

 Support --Adamant1 (talk) 00:35, 27 November 2023 (UTC)

 Support. Some good ideas above from Yann and Jmabel. We could also explore autotranscluding them to the bottoms of the DR subpages themselves.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 00:49, 27 November 2023 (UTC)

 Support. Yes, good idea, esp. with Jmabel’s and Yann’s additions. -- Tuválkin ✉ ✇ 11:34, 27 November 2023 (UTC)

 Support to restrict it to anyone with autopatrol, I think these users are knowledgeable enough to know that the talk page isn't to discuss the deletion. We must create an informal and easy-to-understand AF notice though. -- CptViraj (talk) 12:19, 9 December 2023 (UTC)

Another one, this misplaced comment by ApexDynamo, which I have transferred to the main nomination pages. CptViraj, I don't think even autopatrolled users are still knowledgeable enough to know that talk pages are not proper forums to comment. Example: misplaced comments by Exec8 (which I also transferred soon after initiating this proposal). I suggest the use of those talk pages must be restricted to admins/sysops and license reviewers. JWilz12345 (Talk|Contrib's.) 09:38, 14 December 2023 (UTC)

Search for filetype among user uploads

As I brought up here[2], there does not seem to be a way to search or order uploads by filetype.[3] But at the same time, judged on how many ways editors seem to have found their own workarounds for it, it appears it is a useful feature that a lot of people could need. Seems you can already sort uploads by date by clicking the black arrow, why not by filetype or name, or even size? FunkMonk (talk) 12:49, 6 December 2023 (UTC)

File overwriting filter blocks SVG Translate

In an earlier proposal, users without autopatrol rights were restricted from overwriting files:

• Commons:Village_pump/Proposals/Archive/2023/08#Limit_file_overwriting_to_users_with_autopatrol_rights

Recently, PoliticsMaps used SVG Translate but was blocked from uploading a translation to an SVG file:

• https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&diff=prev&oldid=828424197

The blocking of SVG Translate is unfortunate, but I do not know how frequent it will be. I do not expect new users on Commons to know about SVG Translate, so I suspect the issue is infrequent. If the filter logs show frequent blocks of SVG Translate, then we should look into it. Glrx (talk) 18:11, 6 December 2023 (UTC)

SVG Translate is designed to overwrite an existing file. Many multilingual SVG files are used on language wikis but do not support the wiki's language. For example, the multilingual File:Standard Model of Elementary Particles.svg has seven translations, but it is used on dozens of wikis. There could be a campaign to add appropriate translations to those files, and such a campaign would attract new contributors. Glrx (talk) 19:22, 9 December 2023 (UTC)

 Done I made an exception for the SVG translate tool. GPSLeo (talk) 20:50, 9 December 2023 (UTC)

Technical needs survey

Following multiple discussions on the technical needs of Commons I now created a survey to summarize what the most urgent needs for the majority of the active users are.

Commons:Requests for comment/Technical needs survey

I propose that we finalize the method until 24.12.2023 and in parallel already collect proposals until 14.01.2024. The Voting would start on 22.01.2024. Please make comments on the talk page.

I also propose that we add a link to the survey to the MediaWiki:WatchlistNotice. If no one objects I would add the link on 17.12.2023. GPSLeo (talk) 13:47, 9 December 2023 (UTC)

For those who don't understand European-looking dates, those are: "finalize the method until 24 December and in parallel already collect proposals until 14 January. The Voting would start on 22 January. ... If no one objects I would add the link on 17 December."   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 00:15, 10 December 2023 (UTC)

I updated the survey to reflect this.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 01:18, 10 December 2023 (UTC)

Low quality AI media deletion system

I have seen a few AI generated images on Wikimedia a I am concerned that the rate of new low quality AI generated images will overtake non AI images on Wikimedia commons (it requires a much less effort to generate a image with AI then to make a non AI image) I am proposing a system to prevent this: any AI images that a Wikimedia editor deems "low quality" will be discussed and voted upon. if it is deemed low quality and therefor unlikely to be useful compared with normal images it may be deleted. I think this system will help prevent a flood of low quality AI images from disrupting Wikimedia (wich i think is a Possibility based on how easy it is to make AI images, In the time it took to write this I could have made more then 36 AI images) 50tr5 (talk) 03:07, 13 December 2023 (UTC)

@50tr5: I'm not sure "low-quality" is so easily defined, but I encourage you to participate in Commons:AI-generated media and its talk page, where we are trying to hash out some sort of guideline or policy on AI-generated media. I, for one, hope we will come up with criteria that allow deletion of most AI-generated media. - Jmabel ! talk 18:28, 13 December 2023 (UTC)

"Low quality" is kind of vague and I don't think the project is well served with endless debates over the line is every time someone nominates an image of AI artwork for deletion. Plus the quality shouldn't matter anyway. High quality or not, AI artwork is fundementally at odds with the goals of the project. At least with how it stands now and outside of some extremely rare cases. I like @Gestumblindi: 's suggestion of only allowing for AI artwork that being used on projects though. But with the caviet that unused images should qualify for speedy deletion. Since there's already been enough bad faithed atguing around this already and there shouldn't be a need to relitigate things with every image if we all agree they shouldn't be hosted on Commons to begin with. We could also make an exception for AI artwork that's being used on people's personal pages. Regardless, I think that would be a good middle ground between outright banning it or taking no action at all. Since there's clearly a need to do something about it. --Adamant1 (talk) 18:58, 13 December 2023 (UTC)

They could also be required to be put in separate categories like "AI-generated XY" or "XY in art" rather than "XY" which already is usually the case. This could be used in the search engine where there could be a toggle button to make it not show any AI-generated images (I think I also supported or proposed a filter toggle for NSFW images like sexually explicit scenes as well as gore to prevent such from showing up in unexpected searches). Creating many AI images of low quality in short time is possible since over a year now yet no such flood has occurred here so the concerns are overstated and low-quality AI-generated images are already frequently deleted and I'd support doing that more often for images in Category:Poor quality AI-generated images as well as implementing a more clearly visible 'Warning: This image is AI-generated template' which could also be used in places where images are displayed without their file descriptions such as the search results. Prototyperspective (talk) 19:04, 13 December 2023 (UTC)

I've said it other places, but requiring AI artwork to be put in separate "AI-generated XY" or "XY in art" rather than "XY" categories does absolutely nothing to deal with the issue. Just like it didn't help at all to transfer the fake AI artwork of Giovanna IV di Napoli out Category:Giovanna IV di Napoli. The images were still deleted as out of scope fan art regardless. At least there won't be similar, time wasting debates to the one in Commons:Deletion requests/Files in Category:Giovanna IV di Napoli by Bing Image Creator if AI artwork is mostly banned though. Really, the whole thing has clearly been a massive time suck. One that your at the losing end of. So why not meet everyone else half way and just accept that the best option here is to ban it except in cases where the images are being used on other projects. Instead of acting like putting the images in separate categories for AI artwork is some kind of magical, cure all solution to this when it isn't? At the end of the day the images are going to be deleted regardless if they are in separate categories or not. --Adamant1 (talk) 23:01, 13 December 2023 (UTC)

Because you refuse to take home and address simple rational points like my question about why it would be fan art when COM:Fan art starts with …unofficial artistic representations of elements or characters in an original work of fiction – what's the original work of fiction? It's not fan art since it is depicting a real historical character in interesting sceneries. Like in the prior debate you keep on making claims without reasons / explanation such as that it would to nothing to deal with the issue without explaining why when I explained explicitly how exactly it would deal with the issue. AI art has tremendous potential, it's like banning all images made or modified with Photoshop...you really think that is a good idea? Separate categories aren't needed either. Prototyperspective (talk) 23:11, 13 December 2023 (UTC)

It's nothing like banning all images modified with Photoshop. That's the problem with your approach to this. You use completely ridiculous comparisons that absolutely nothing at all to do with the topic and then act like it's a valid point that people are just unwilling to address when they don't indulge in your side meaningless side tangents. At least have an argument that's relevant to the topic. Saying banning AI artwork would be like doing the same for images edited in MS Paint is just laughable on it's face though. Plus it has absolutely nothing to do with this anyway. You act like we shouldn't have any standards what-so-ever just because people modify images in photo editing apps. It's not a serious argument. --Adamant1 (talk) 23:26, 13 December 2023 (UTC)

just laughable on it's face your approach right alongside calling me Your probably one of those people who think Bitcoin is going to replace fiat currency any second now to aren't you? Lmao.. Your premise is that AI art is useless, we can argue whether or not it is as useful as Photoshop, I think it could be more useful since eventually you could create a high-quality image of anything you can imagine – but that it can be useful is enough of a reason to not ban it based on your unsubstantiated assumptions and quite clear anti AI bias. I won't continue this debate with you from now on. It just puts walls of text where there should be actual arguments and actual addressing of points. It's a tool usable for so many purposes and free media gaps. Prototyperspective (talk) 23:41, 13 December 2023 (UTC)

it can be useful is enough of a reason to not ban it based on your unsubstantiated assumptions and quite clear anti AI bias. It seems like essentially everyone else disagrees with you. But all you do is chalk any minor disagreement with your opinions up to ignorance or anti AI bias.

Your premise is that AI art is useless That must why I've said multiple times now that we should keep images that are being used on other projects. Just like how you've repeatedly treated me like I have no experience with AI artwork when I've said at least 4 times that I have a Flickr account that I upload images from Dall-E to. All you do is box ghosts. Apparently your just that incapable of discussing this in an honest, good faithed way. Be my guest and don't debate it with me anymore though. I'm sick of repeating myself over and over about things that your either incapable or unwilling of getting anyway. So I could really care less. I'm sure cooler heads then yours will ultimately prevail. --Adamant1 (talk) 00:02, 14 December 2023 (UTC)

AI art does have potential but it has not reached a stage (at least with the AIs normal internet users can get) where it can reliably pump out images that look like something someone would use in like say a presentation (compared with normal images) 50tr5 (talk) 15:54, 14 December 2023 (UTC)

Agree. Prototyperspective (talk) 16:06, 14 December 2023 (UTC)

I don´t know where you got that info from,(you don´t give any sources, like the other guy) but some of the stuff out there is convincing enough, that I can only identify a fake by it´s context. Anything with sex and celebrities - most likely AI, but grainy presumably "historical" photographs in lower res on flickr ? I can´t tell. Most cheesy artifacts and imperfections in a high res AI work would disappear when scaling it down and reducing colors. Alexpl (talk) 19:05, 14 December 2023 (UTC)

Check out Fooocus. I've been using it for a minute now and it produces some pretty crazy accurate stuff. The discussion of quality is really just a re-hearing though. At least it is in most cases, since AI artwork is OOS fan-fiction at best in most (if not all) cases anyway. But there's no reason that we need AI artwork in the first place with the rare instances where it is. Like an image of a cat. There's already millions of freely available images of cats out there. So there's no reason to bother with an AI generated image of a cat to begin with.

The only instance where it might be useful is with images of objects or people where there is no freely available alternatives. But it's already been established that it falls flat in those instances. The AI artwork of Giovanna IV di Napoli being one example, but I'm sure there's many others. It would be totally ridiculous to allow for say AI generated images of old west towns where there's no publicly available, free images of them. So realistically what's the actual point in allowing for AI artwork to begin with? Like what's the actual benefit to the project outside of nonsense claims that the technology is cool and anyone who disagree just hates AI? Because at the end of the day we seem to be doing perfectly fine without it. And a few people can throw tantrums over it being banned, but there's no reason not to ban it if there isn't even a valid use case for it to begin with. --Adamant1 (talk) 23:14, 14 December 2023 (UTC)

Well now some argue that it's too inaccurate and low-quality while others argue it's too high-quality/-resolution/accurate. There's already millions of freely available images of cats out there. So there's no reason to bother with an AI generated image of a cat Agree if it's just a mundane cat without any unique noteworthy features worthy of inclusion such as a realistic cyborg cat, a cat according to some mythological tale, an image showing an anthropomorphic cat society, or a fictional cat breed or the cat being not the only main content of the image. Saying "it shows a cat" is not enough, it should be "it merely shows a cat without adding much". While no such restrictions are in place for other media, I wouldn't object to setting some reasonable requirements if people think that would make things better. The only instance where It can also be higher quality for subjects for which one or a few images are available, it doesn't mean these need to be used but it can be good to have them. Moreover, it's probably not a good approach to just assume you have thought of every constructive application. I already listed many use-cases why do I need to repeat over and over. From illustrating what an art style looks like to depicting a concept or a subject on fiction/art. From sustainable city design to art movement/aesthetics, extinct animal species and scientific concepts. It's a tool for countless purposes and I've been explicit and exhaustive in exemplary valuable applications I explained. Prototyperspective (talk) 23:32, 14 December 2023 (UTC)

Most AI images are out of scope. I would encourage you to nominate any that aren't in use and don't seem likely to be used for deletion per COM:EDUSE. The Squirrel Conspiracy (talk) 23:24, 14 December 2023 (UTC)

Thanks to Nosferattus, Jmabel et al for Commons:AI-generated media discussion. Agree this has been a problem - there have been some genuinely low quality "AI" images uploaded (eg supposed portraits of people with body parts in incorrect places); there have also been IMO too many uploads of images which superficially look good aesthetically, but are not useful as educational material for in scope subjects. Some uploaders of such material seem indignant that others on Commons object - but just being an AI image, even a significantly better than average AI image, does not in itself mean it belongs on Commons. There are many other websites online for sharing images. Commons is not social media nor personal artwork sharing site. -- Infrogmation of New Orleans (talk) 23:56, 14 December 2023 (UTC)

 Comment Here's an alternative proposal that, in my opinion, achieves similar goals while minimizing user intervention. 1. Automate AI image deletion: Delete unneeded AI images after a specified period of inactivity (e.g., 3 months) from projects. This declutters the Commons without requiring manual intervention. 2. Standardize filenames: Rename remaining AI images to a consistent format like AI_Image_Filename.jpg. This helps users searching by filename easily identify and avoid unintentionally using them in active projects (and they can still use them if AI serves their purpose). AI images require minimal effort to generate. Leaving unused ones clutters the Commons and can lead to unintentional use. Anyone needing a similar image can readily create a new one with current AI tools. I believe this approach balances practicality and potential misuse of AI-generated content. What do you think? Rkieferbaum (talk) 00:58, 16 December 2023 (UTC)

@Rkieferbaum: sorry, but I don't like it at all. Among other things, I'm extremely opposed to introducing automated deletion. I do not trust a bot-based rule to decide what is "unneeded". For a simple example, but one that I think is sufficient to show the problem, consider an image where there has been some back-and-forth as to whether to use it in a Wikipedia article. There is no reasonable way for a bot to be able to tell that has been going on. Similarly, a bot cannot determine that a particular image is very likely to be used outside of WMF projects. And (unless it's by human tagging) a bot cannot tell that an image is part of a set intended to track the evolving behavior of a particular generative AI tool over time.

I'd be open to the naming thing, but I don't necessarily think it is a good idea. I'm always hesitant to rely on any meaning to filenames. Files get renamed. Properties should be tracked with templates, categories, and SDC, not filenames. - Jmabel ! talk 04:04, 16 December 2023 (UTC)

+1 The AI nature of a file has to be clear without relying on people choosing the correct category. Let´s make an "AI" in the filename mandatory. Alexpl (talk) 05:52, 16 December 2023 (UTC)

+1 Agree with Jmabel and strongly oppose the proposal #1 but would support the #2 if people think that would be useful and no better option is found and feasible. A better option could be only displaying a tag 'AI image' on the thumbnail or adding that (or e.g. 'Made using AI') to the filename without the file having to be named so. Prototyperspective (talk) 13:04, 16 December 2023 (UTC)

+1 to the second proposal. I suggested something similar in the last discussion. Although it's a toss up for me between a template that can be added to files or requiring the file names indicate the image was created by an AI generator. Really, both approaches have their pros and cons. I'm against any kind of automated deletion process though. But the two proposals aren't mutually exclusive either. The best option is probably Gestumblindi's proposal in conjunction with having a way to indicate the files are generated by AI, however its ultimately implemented. --Adamant1 (talk) 16:00, 16 December 2023 (UTC)

The deletion being automated isn't as important as avoiding a scenario where each image has to be examined by multiple users to be deemed low quality. I think we should avoid at all costs a situation where each single low quality image takes a few seconds to generate and upload but consumes a hundred times that to be deleted. An alternative to the automated process would be allowing something like PROD in such cases. Unlike with regular uploads, with AI images the "burden of proof" of usefulness should lie with whoever thinks they should be kept. As for the file naming, I think it's important that the name itself be changed rather than the alternatives, because as far as I can tell anything else wouldn't be as conspicuous and could easily be missed within the other platforms. Rkieferbaum (talk) 02:00, 17 December 2023 (UTC)

I'm against any kind of automated deletion process. However, it is an issue that there are potentially countless AI-generated images of little value. I therefore still stand by my proposal from the recent VP discussion to apply stricter criteria for AI images than COM:EDUSE would usually provide, and only accept images that are in use in Wikimedia projects. Those, however, we must accept (unless there is a tangible copyright / derivative work concern for a specific file) per COM:INUSE. Delete the rest - but not with an automated process. Gestumblindi (talk) 12:01, 16 December 2023 (UTC)

Image upload UI requests

Hello! Not sure if this is right place to ask but wanted to put in a couple of requests for tweaks to the upload UI. I am a mobile-only user FWIW, editing via a Safari browser in an iPhone 11.

(1) Expand field for Where did you find this work? Enter the website, the book, or another source.

Right now this field is one line high and it's very hard add more than four or five words because I can't see formatting or navigate very well.

Most historic images from digital libraries come with 30 lines of metadata that should ideally go here but right now I would be adding text/code almost blind which feels weird.

(2) I can't enter any text in Enter a different license in wikitext format

When working on commons.m.wikimedia.org on a Safari browser on my iPhone 11, I can't click into the field where you are supposed to enter licenses not otherwise listed such as {{PD-textlogo}} or {{PD-CAGov}} in the field label Enter a different license in wikitext format so I just leave it blank and circle back later--except half the time I forget until I get the deletion warning and then run back in a panic to add it.

please and thanks to anyone who looks at this and let me know if you have any Qs. Jengod (talk) 19:33, 16 December 2023 (UTC)

@Jengod: Can you use a clipboard app to compose what you want to put there, and then paste? I do that on my Android phone from time to time.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 20:14, 16 December 2023 (UTC)

Thank you warmly for the good suggestion @Jeff G. (love a good notepad note!) I'm just one small user and I would not even mention it if it was just for my own convenience, I just was thinking that the single-line-sized field somewhat visually discourages users from providing full descriptions. I've been around for a billionty years (roughly) and you'll never be rid of me (bwahaha), just thinking about ways to make things friendly/low-friction for new/novice contributors. Jengod (talk) 21:19, 16 December 2023 (UTC)

@Jengod: You're welcome. Does a laptop that's not hardwired count as "mobile"? If so, I've been editing mobile-only for over a decade. I've also been hearing "umpteen bazillion" as an exaggerated large number lately. In addition, if I've told you once, I've told you a million times, stop exaggerating. :)   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 23:38, 16 December 2023 (UTC)

FWIW Commons:Upload Wizard is at least in theory the central point that should link out to places where the Upload Wizard is discussed, and I recently updated it to say that it looks like as of late 2023, most recent discussion is taking place at Commons talk:WMF support for Commons/Upload Wizard Improvements. - Jmabel ! talk 00:00, 17 December 2023 (UTC)

Lol @Jeff G. and TYSM @Jmabel. I'll swing over there when I get a minute Jengod (talk) 00:30, 17 December 2023 (UTC)

Not sure on which forum to ask this question

Now, after the copyright questions on Soviet postcards have been resolved by the commnuity, I'm re-starting uploading my collection. However, I ran into the slight issue: due to the fact that these postcards are 40+ years old, the paper has yellowed out, on some postcards more, on some postcards less. Question: do we have a template warning the user about that? So they do not think that older artifacts were really of that dull "aged" colour? -- Wesha (talk) 21:17, 16 December 2023 (UTC)

I think writing in the description field should be sufficient. GPSLeo (talk) 21:56, 16 December 2023 (UTC)

Yeah, but the point of template is to do just that: simplify the repetitive task. If you saying that such template doesn't exist, I can make one. -- Wesha (talk) 22:11, 16 December 2023 (UTC)

Nothing wrong with creating a template for that. I'd make it very general: that this is a scan of an old, discolored work (and possibly encouraging that if no color-corrected version exists, one would be welcome under a distinct filename). - Jmabel ! talk 00:03, 17 December 2023 (UTC)

I'd call it {{Discolored}} or maybe {{Aged}}.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 00:08, 17 December 2023 (UTC)

"discolored" is better than "aged"; "aged" could refer to a lot of things besides the state of the media. - Jmabel ! talk 00:49, 17 December 2023 (UTC)

@Jmabel Right, we wouldn't want to offend older human subjects of photos, but inanimate objects don't care.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 01:10, 17 December 2023 (UTC)

How's this for starters? (please feel free to edit it directly)

This work has been digitized many years after its creation. The colors may have altered over time due to the deterioration of paper, pigments or other materials used. If you wish to upload a color-corrected version of this image, please do so under a separate filename and link the file pages with {{Derivative works}} / {{Derived from}}.

-- Wesha (talk) 01:20, 17 December 2023 (UTC)

I think it's fine, but I wouldn't use such a glaring red "warning" color for the template. It's interesting and important information, but not that dramatic. Maybe use grey? Blue? Gestumblindi (talk) 15:01, 17 December 2023 (UTC)

Good move, Wesha. As for the red color, I  agree with Gestumblindi. -- Tuválkin ✉ ✇ 15:23, 17 December 2023 (UTC)

I did the best that I could given my knowledge of templates over here on Commons. For example, I've noticed that most of them use i18n but I wasn't able to grok that in the short period of time. So please, by all means, Be Bold and join in improving the template! -- Wesha (talk) 18:42, 17 December 2023 (UTC)

Now it's a little bit less dramatic. Feel free to change the colour by modifying the parameter |type= (see Template:Mbox#Examples). Strakhov (talk) 19:32, 17 December 2023 (UTC)