Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

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/08.

COMMONS DISCUSSION PAGES (index)
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.

Enable textured 3D files on Commons[edit]

Broad consensus for allowing this. Already tracked in Phabricator as T246901.
Tracked in Phabricator
Task T246901
The Squirrel Conspiracy (talk) 16:50, 8 September 2023 (UTC)Reply[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Featuring 3D renderings of notable objects and places offers great opportunities for improving Wikipedia articles by making them both more engaging for readers whilst also helping them better comprehend the subject.

Support for featuring 3D renderings of objects has become increasingly common and better supported on the internet generally; however this support is not currently matched on Wikimedia Commons thereby limiting Wikipedia's ability to feature 3D objects.

As stated in a blog post on the publication of the original basic 3D support in Commons (source below):

In the future, after feedback from our community of volunteer editors, we’ll consider adding support for even more complex file types that support features like textures.

The time to add support for these features is now. Most modern smartphones are able to create 3D-Scans of smaller objects or even complete buildings rights now, and there is no way to upload and display them in Wikimedia projects!

Possible use cases of colorful, interactive and complex 3d models in Wikipedia articles:

  • models of extinct species like dinosaur reconstructions
  • the inside of historical rooms (example)
  • all kinds of smaller interesting objects
This is great, but pretty boring. We need color! ;)

Resources:

Kristbaum (talk) 10:21, 24 July 2023 (UTC)Reply[reply]

Wikimania poster and meetup[edit]

Poster by Discott that will be displayed at Wikimania 2023.

Hello everyone, for those of us attending Wikimania 2023 in person I will be hosting a meetup to discuss this issue with the objective to increase awareness of this amoungst Wikimedia Foundation management. This will be done in front of the poster we are displaying during the poster session on Thursday 17 August at 17:00 to 19:00 Singapore time (9:00 UTC to 11:00 UTC). Let me know here if anyone wants to join digitally and I will try to setup a Jitsi hangout so people not physically there can also join in (depending on practicability). We will also be talking about other aspects of 3D support on Wikipedia as well, such as technical considerations. We can talk about this issue more later on at the conference, both in person and online, at the Hackerthon space. --Discott (talk) 14:52, 31 July 2023 (UTC)Reply[reply]

WMF C-Levels and other staff talking about how to best action 3D support on Wikipedia.
Hello everyone and apologies for the long delay in getting this update done. The poster presentation on 17 August seemed to go very well and we got strong support from both the community members present as well as the WMF staff that visited us. Encouragingly the WMF staff, including the C-levels that were present, immediately started discussing how to implement the 3D support. One idea was to enable Wikipedia to feature/display 3D objects that are stored on a site that is already optimised for hosting 3D objects like Sketchfab; the logic being that this would be a quick and relatively effortless way to experiment with the idea so as not to divert too much of the already scarce development talent the WMF has, and if it is a successful experiment then it can be deployed properly with full hosting support deployed on Commons. One of the other WMF staff pointed out how the concept of piping content from a website not affiliated with Wikipedia/Commons might be controversial within the community and so it might be best just to go 'all in' rather than doing the experimental rout. I stated that I was 'method agnostic' but could see the value in trying out the experimental route. I however now regret that I did not also, at the same time, echo the concern about sourcing from a non-Wiki project as a possible issue for the community. A final concern by another WMF staff member was the possibility of people using textured 3D objects to upload pornographic content that is not allowed on Commons, fearing that is might create an extra review burden on the community. Concerns on the 'how to do it' aside, the important thing is that people liked the idea of doing 3D support, immediately recognized its immense potential and possible value for Wikipedia & Commons, and also want to see it done which was the purpose of this poster. So mission successful! Now onto the next part of this: "how to get it done?"--Discott (talk) 08:43, 30 August 2023 (UTC)Reply[reply]

Voting[edit]

 Support This would be an valuable addition to Wikimedia Commons, as there is not yet a non-commercial platform for 3D renderings and models Ionenlaser (talk) 08:00, 26 July 2023 (UTC)Reply[reply]

 Support чтобы обойти загрузку текстуры в 3д модель можно применить облачный формат E75 там нет текстур а только миллионы точек с информации о координатах и цвете точки в итоге визуально мы видим 3д модель но по факту это массив точек это очень удобный формат и он создается только 3д сканером в момент сканирования--Masterhappiness2022 (talk) 12:15, 26 July 2023 (UTC)Reply[reply]

Всем привет! у меня есть цель и я прошу помощи в ее реализации. Я Занимаюсь 3д сканирование и хочу оснастить каждую статью википедии 3д моделями земных достопримечательностей. Википедия очень правильное место и лучше не придумаешь! Я могу загружать и в STL но нужно чтоб ваши специалисты добавили возможность смотреть эти 3д модели с текстурой(в цвете). Да я понимаю Что для википедии это дополнительная работа. но в этом направлении нужно точно развиваться ведь не за горами мета вселенная. Вот представьте человек открывает статью в википедии скажем про пещеру или пирамиду или архитектурное сооружение и прочитав и посмотрев фото этого объекта он получает возможность посмотреть виртуально 3д модель этого объекта! Я обладаю всем нужным оборудование для реализации этого проекта в википедии и оно очень дорого мне обошлось, я хочу чтоб в википедии была такая возможность совершить путешествие к тому месту куда не могут приехать например люди с ограниченными возможностями или школьники и студенты которые не имеют финансовой возможности но Википедия предоставляет им эту возможность совершить бесплатно ,виртуально. Я вас очень прошу поднять этот вопрос на совещании Руководства Википедии т.к. эта возможность также повысит популярность википедии и обретет новый современный подход к статьям и это уже будет не просто текстовые статьи а полное погружение во все нюансы которые не описать текстом. --Masterhappiness2022 (talk) 12:18, 26 July 2023 (UTC)Reply[reply]

You voted twice? -- Tuválkin ✉ ✇ 15:24, 26 July 2023 (UTC)Reply[reply]

 Support We should have (almost?) all free file formats. —Justin (koavf)❤T☮C☺M☯ 16:54, 26 July 2023 (UTC)Reply[reply]

Agree. Almost every file format has unique functions, that can be useful, depending on the purpse --PantheraLeo1359531 😺 (talk) 12:33, 4 August 2023 (UTC)Reply[reply]

 Support Just a few weeks ago I was having a discussion about the lack of support for the formats that many GLAM entities use for their collections of 3D models. This would definitely facilitate mass importing of such collections. --Waldyrious (talk) 00:49, 27 July 2023 (UTC)Reply[reply]

 Support This seems like a no-brainer and having textured 3D models of things like extinct species would be really cool. --Adamant1 (talk) 14:36, 28 July 2023 (UTC)Reply[reply]

 Support I am, as I write this message of support, preparing a poster for Wikimania 2023 advocating for support to be given to developers to make this a reality (along with support for other aspects of hosting 3D objects on Commons). This area of 3D browser interactivity has come a long way over the past couple of years. There is also a great deal of 3D content out there that is copyright compatible for uploading to commons, it seems such a shame to be preventing people (due to a lack of technical support) from using that content here and on Wikipedia. Its the sort of modernization that I feel is needed. --Discott (talk) 16:20, 28 July 2023 (UTC)Reply[reply]

 Support I love 3D renderings of objects. 20 upper 06:43, 30 July 2023 (UTC)Reply[reply]

Tracked in Phabricator
Task T246901

This has been dicussed before; see Phabriactor ticket T246901. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:14, 26 July 2023 (UTC)Reply[reply]

Thanks for adding the template! It has of course been discussed before and on different forums, but it probably is good to put this issue in front of people on Commons to gather support and future use cases, so WMF has an easier time to allocate resources to this :) Kristbaum (talk) 16:12, 28 July 2023 (UTC)Reply[reply]
Strong Support, there are so many projects in the digital humanities, that might supply data to make their results visible. --h-stt !? 20:22, 29 July 2023 (UTC)Reply[reply]

 Support, this would finally grant Commons a useful (for an average person) feature which would make it better than a generic file bank service. I would be glad to upload some 3D scans of my collection if it were technically possible. Drogosław (talk) 20:10, 30 July 2023 (UTC)Reply[reply]

  •  Support, obviously. I still find it odd that the Wikimedia Foundation (WMF) acts as if it needs to get community consensus for every small technical improvement, especially since it just assumes that "everything is disallowed unless explicitly allowed" which kind of goes against the spirit of open-wiki's where improvements should always be welcomed unless we can think of a reason to exclude them. 3D scanning public domain objects doesn't create new copyrights and a lot of museums around the world are now scanning old cultural heritage. The reason why nobody outside of Wikimedia websites takes the Wikimedia Commons seriously is because we are too slow to adopt new technologies and utilise existing technologies, 3D objects are the latest in a long list of technologies that will be useful in other technologies. 3D objects are also useful for Augmented Reality (AR) and Virtual Reality (VR), now imagine if we'd have interactive scans of places like the Great Pyramid of Giza freely available at the Wikimedia Commons that both educators and video game developers could download knowing that it's from a free source. This technology has so much potential and we'd be shooting ourselves in the foot by not allowing it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:04, 30 July 2023 (UTC)Reply[reply]
  •  Support, per koavf, with thanks. --SJ+ 23:22, 31 July 2023 (UTC)Reply[reply]
  •  Strong support As a creator of 3D models, I am in favor with this idea. I also support adding new 3D model file types that support texturing. But there are some other reasons for more file formats: You need to do less converting from other repositories. But other formats also allow to create rigged models, which means, you can rotate an arm of a 3D model for example. This is not supported by STL, which is currently the only allowed filetype on Commons. STL is good for 3D printing, but only covers the mesh itself. It covers no surface properties, no textures, no transparency, no rigs, no animation and more. Some models make even no sense at all, whenn textures or properties are missing. Models of windows without transparency are useless, and so are signs without textures. There are some Creative Commons (including CC0) repositories of texture mapped models (for example by NASA, that show probes and satellites with textures). Having these models without texture reduces their educational value severely. I also remember converting COLLADA (DAE) files from 0 A.D., a free strategy game, to STL. This took much time. So in short: I really hope that this idea will be reality soon, in combination with more free mesh or model filetypes, so we get a broader bandwith of 3D models with much more features than only the mesh itself. AFAIK DAE (COLLADA), OBJ and STL are open filetypes. PLY (free???) allows the storage of textures with the meshes. The Blender filetype also offers a huge range of additional features (as it is a scene filetype), but it has possible backdoors. I hope, that those filetypes could be considered to be added. Also interesting might be the implementation of file types that are made for point clouds. This is in important topic in scanning of 3D objects via laser scanning. One filetype is *.laz --PantheraLeo1359531 😺 (talk) 12:19, 4 August 2023 (UTC)Reply[reply]
  •  Strong support There are literally hundreds of 3D file formats (open, proprietary, commercial) and are widely used in academia, research, 3D games, AR/VR, design, industry, etc. Hence, some open 3D file formats to be considered to start with: - PLY (Stanford polygon file format): suitable for preservation (ASCII version), allows colour, transparency, surface normals, texture coordinates, and data confidence values. - OBJ (includes optional .mtl and .jpg image files): suitable for preservation (ASCII format is preferred) of wire frame or textured models. - X3D (ISO standard XML-based format developed by the Web3D consortium): suitable for preservation and recommended for complex 3D content. - STL (Stereolithography or Standard Tessellation Language): suitable for preservation for very basic datasets (ASCII format only stores 3D geometry, i.e. no textures, whereas the binary version with the help of an extension also saves colour information and requires less storage space). - Pointclouds: exchange and archive (e.g., ASCII TXT, ASTM E57 format) or visualisation (not sure if it makes sense to create, for example, a derived PLY?). As for the visualisation of 3D models, perhaps 3DHOP (developed by Visual Computing Lab, ISTI-CNR) might be somewhat helpful. It's «an open-source framework for the creation of interactive web presentations of high-resolution 3D models, oriented to the Cultural Heritage field. 3DHOP allows the creation of interactive visualization of 3D models directly inside a standard web page, just by adding some HTML and JavaScript components in the web page source code. The 3D scene and the user interaction can be easily configured using a simple 'declarative programming' approach. By using a multi-resolution 3D model management 3DHOP is able to work with high-resolution 3D models with ease, also on low-bandwidth. 3DHOP does not need a specialized server, nor server-side computation, and does work directly inside modern web browsers, no plug-ins or additional components are necessary.» https://vcg.isti.cnr.it/3dhop/
Veryfiner (talk) 17:20, 4 August 2023 (UTC)Reply[reply]
  •  Support. Commons is a free media repository; I believe that having educational and freely licensed 3D renderings and models would align well with the project scope. — Red-tailed hawk (nest) 03:04, 8 August 2023 (UTC)Reply[reply]
  •  Strong support I have a number of photogrametric 3D models on Commons, all of which would benefit from texturing: even in simple cases, texturing gives indications of materials (is a statue made of bronze, marble, clay...?), and conveys verisimilitude through little details such as weathering or ambient occlusion.
No indication of material, and scarcety of details
  • Terracotta object renders like clay

    Terracotta object renders like clay

  • Plaster object renders like clay

    Plaster object renders like clay

  • Marble object renders like clay

    Marble object renders like clay

More importantly, some models suffer greatly from being only clay models: for instance polychrome archæological artefacts are improperly represented by clay models.

polychrome archæological artefact improperly represented by an untextured models
  • polychrome archæological artefact improperly represented by an untextured model: 3D clay model gives volumes but misrepresents colours

    polychrome archæological artefact improperly represented by an untextured model: 3D clay model gives volumes but misrepresents colours

  • polychrome archæological artefact improperly represented by an untextured model: photograph gives colours but not volumes

    polychrome archæological artefact improperly represented by an untextured model: photograph gives colours but not volumes

  • Model looks damaged (nose)

    Model looks damaged (nose)

  • Texture gives information that the damage is on the object rather than on the 3D model.

    Texture gives information that the damage is on the object rather than on the 3D model.

Finally, on the technical side, not having textures forces us to upload high polygon models. The possibility to embed bump maps and displacement maps would allow conveying the same amount of detail with much smaller models (one order of magnitude fewer polygons at least). I very much hope this proposal comes to fruition. Rama (talk) 05:51, 9 August 2023 (UTC)Reply[reply]

  •  Strong support A more structured 3D viewer would be an asset not only for Wikimedia, but also for scientific projects that previously had to host their files on their own servers or with commercial providers. The option to add footnotes to the 3D models would be particularly great. Please! Please! Please! -- Frieder_Leipold (talk) 14:20, 24 August 2023 (UTC)Reply[reply]
  •  Strong support 3D models are a powerful feature, and their presence makes Commons and Wikimedia stand out. (I don't see 3D models used to explain concepts anywhere else.) Adding the ability to convery color and texture will make them even more useful. The Quirky Kitty (talk) 08:10, 14 September 2023 (UTC)Reply[reply]
  •  Comment We also need a newer version of the 3D viewer with better shadow simulation, maybe effects like AO and more. And we have the problem that meshes above around 170 MB won't get a preview image. --PantheraLeo1359531 😺 (talk) 09:04, 27 August 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Prevent IP users from creating deletion requests[edit]

1 . it is not that hard to create an account. IPs are so hard to follow, which IP created good or bad DR?? how can we prevent this? even, they are unable to upload files but can request for deleting?

2. loooooook at that DR, bro thought we will delete a file because it is "nonsense" 💀💀💀. these users are just slowing our work. so please, stop IPs for creating DRs!!!! ----modern_primat ඞඞඞ TALK 21:35, 1 August 2023 (UTC)Reply[reply]

Looks to me like that is probably a deletion request for an out-of-scope personal photo. Badly formed DR, but we get those from logged-in users, too. - Jmabel ! talk 21:38, 1 August 2023 (UTC)Reply[reply]
I've deleted the user's files as F10/G10. They're already blocked on enwiki as NOTHERE (and possibly socking there as en:User:Jio Giga Fiber). As for the IP, it's not exactly the most useful DR. but better to draw attention to out-of-scope/spam files that way than not at all. Pi.1415926535 (talk) 22:26, 1 August 2023 (UTC)Reply[reply]
Just to be clear: User:Pi.1415926535, you are saying that the uploader is blocked, not the IP who User:Modern primat is complaining about, correct? - Jmabel ! talk 03:16, 2 August 2023 (UTC)Reply[reply]
@Jmabel: Correct - en:Bong Girl Creation is blocked on enwiki (not on Commons). IP 181.43.1.29 is not blocked on Commons and has not been active on other wikis. Pi.1415926535 (talk) 03:34, 2 August 2023 (UTC)Reply[reply]
The proposal appears to be to prevent DR's from IP users, in general.  Oppose "these users" may still form valid DR's, just like named users may create unreasonable DR's. --Enyavar (talk) 05:47, 2 August 2023 (UTC)Reply[reply]
Indded «named users may create unreasonable DR's» and if they persist they may be sanctioned for it. On the other hand, unlogged users cannot be sanctioned for anything because IP addresses are volatile and one can always reappear under a new one. Why is this so hard to understand? -- Tuválkin ✉ ✇ 15:32, 25 August 2023 (UTC)Reply[reply]
 Comment: Maybe the English Wikipedia essay “Wikipedia:IP editors are human too” (which, by the way, is an English Wikipedia essay, not a Commons policy nor a Commons guideline) should be updated in the light of so-called A.I. having become cheaply available. And when I say updated, I mean completely upended. Frankly, I have been on the recieving end of much fingerwaving about how I (as a internet fossil who started using networked computers in 1984) should update my views on how to do stuff online, it’s sadly now my turn to warn (as apparently few seem to have comprehended this notion) that many “people” we intertact with online are nor really individual humans thinking and acting real time on their own, and one way to be fairly sure about those who are is to trust continued, consistent pseudonyms. I.P. addresses are inherently volatile and one cannot seriously engage in good faith discussions with the people (or merely people-initiated processes?) behind them. I.P.s should be allowed to contribute, sure (who run away with Modern primat’s goalposts?!), but should not take part on discussions — for the same reason they are not allowed to vote. -- Tuválkin ✉ ✇ 19:33, 2 August 2023 (UTC)Reply[reply]
  • Vandalism deletion requests are a very minor problem compared to the problems caused by other types of vandalism. I would support a general ban for IP edits but just do not let them create deletion requests does not solve any problem. --GPSLeo (talk) 18:39, 2 August 2023 (UTC)Reply[reply]
  •  Support wholeheartedly! (And thanks to Modern primat for creating this.) -- Tuválkin ✉ ✇ 19:33, 2 August 2023 (UTC)Reply[reply]
  •  Oppose In my experience, I have not noticed a particular problem with deletion requests filed by IP users in comparison to requests filed by logged-in users. We should stay as open as possible unless there is a pressing need, and I don't see that pressing need in this case. Gestumblindi (talk) 19:44, 2 August 2023 (UTC)Reply[reply]
  •  Oppose totally agree with Gestumblindi. IP requests are not necessarily worse than DR by logged-in users. This solves nothing. Moreover, I feel anyone should be able to request deletions, including incidental users (i.e. IP users). This should not be complicated with requiring log in. --P 1 9 9  ✉ 20:11, 2 August 2023 (UTC)Reply[reply]
  •  Support This would save a lot of admin time needed to deal with invalid and malformed requests. Yann (talk) 20:42, 2 August 2023 (UTC)Reply[reply]
    The admin time saved by banning IPs from creating deletion request in marginal compared to the admin time needed for all other things IPs do including removal of licenses resulting in accidental deletions. GPSLeo (talk) 04:34, 3 August 2023 (UTC)Reply[reply]
    There's an exact dozen of DRs I just had to tag with {{Speedy keep}} because they incurred against COM:INUSE, all filed by a single ip within 24h. I think there’s two for each of the admins who said in this discussion they don’t mind closing DRs. -- Tuválkin ✉ ✇ 22:28, 3 August 2023 (UTC)Reply[reply]
    I do not said that there is no problem. But if there are 20 nonsense deletion requests every day this would be very minor compared to the some hundred cases every day where they add nonsense text, change the author or remove the license. GPSLeo (talk) 04:48, 4 August 2023 (UTC)Reply[reply]
    And you point is…? I cannot even parse the argument that since IPs poop all over the chessboard, there’s no reason to support this proposal. What, then? Is there a standing proposal to block all IP editing? Where it is?, I wanna support it (maybe I don’t, but anyway). There’s none currently? Okay, so why not some incrementalism and support this one small step now and deal with the rest later? -- Tuválkin ✉ ✇ 12:43, 18 August 2023 (UTC)Reply[reply]
  •  Oppose banning IP users who are able to edit from creating deletion requests. I'm actually, like GPSLeo, fairly open to banning all unregistered editing (although I could probably be convinced otherwise, and the sysadmins aren't open to it so it doesn't really matter), but I don't see anything special about deletion requests that necessitates this. —‍Mdaniels5757 (talk • contribs) 02:04, 3 August 2023 (UTC)Reply[reply]
  •  Oppose Concur with Mdaniels5757 and GPSLeo, and I actually think it would make more sense to ban IPs from nominating files for speedy deletion and 7-day deletion since there's less scrutiny there; if IPs are to continue to be allowed to nominate files for deletion at all, DR is actually the preferred way for them to do it. -- King of ♥ ♦ ♣ ♠ 16:15, 3 August 2023 (UTC)Reply[reply]
    Wait, what?! I.p. can nominate speedy deletions, too, not only simple DRs? (Swoons!) -- Tuválkin ✉ ✇ 22:34, 3 August 2023 (UTC)Reply[reply]
    Well, an admin still has to check whether the (speedy) deletion request has any merit. Gestumblindi (talk) 18:02, 8 August 2023 (UTC)Reply[reply]
    More needless work piled on admons, the. It would be interesting to contrast the oppsing and supporting votes cast by admins in this proposal and compare their respective activity in cleaning up after IP activity. -- Tuválkin ✉ ✇ 00:31, 23 August 2023 (UTC)Reply[reply]
  •  Oppose I'd probably support a general ban on IP Editors since there's plenty of places outside of DRs where they are a nuance, but singling out DRs just seems like the wrong way to go about it. --Adamant1 (talk) 22:28, 3 August 2023 (UTC)Reply[reply]
    Yes, let’s not enact a rule against the smothering of kittens because there’s mean people around who also drown them: Unless we can have a rule against both smothering and drowning, no kitten should be saved! (This is inspired in the wikilove template about «A kitten for you!»; it just means I cannot understand that reasoning behind that argument.) -- Tuválkin ✉ ✇ 22:33, 3 August 2023 (UTC)Reply[reply]
    In German-language Wikipedia, there are also occasionally calls to ban IP editors from filing deletion requests, and I have always asked for actual statistical data to back the perceived issue up (that is, showing that the percentage of "bad" IP deletion requests is much higher than of "bad" deletion requests by logged-in users). As it turns out, people could never back up this "gut feeling" with actual data, and the percentage of deletion requests by IP users that result in a deletion (meaning that, presumably, the DR was correct, as an admin accepted it and deleted the article) is also fairly high. - Here on Commons, I think that there are many more DRs by logged-in users anyway, and of the small percentage of IP DRs, many are also fine. Gestumblindi (talk) 10:03, 4 August 2023 (UTC)Reply[reply]
    I think the dewiki discussion is not comparable to the problem here. On dewiki the discussion is more about sockpuppety and harassment. Here we are talking about simple vandalism or accidental clicks on the wrong button. GPSLeo (talk) 11:15, 4 August 2023 (UTC)Reply[reply]
    At least from what I've seen IP editors are mostly fine in deletion requests. They do a lot of vandalism editing to the village pump and other main talk pages. That's not to say they aren't an issue in DRs though. Just that it isn't a unique problem. So I don't think it's worth passing a proposal that treats it like one. Although on the other hand maybe it would be a good way to test the waters. Who knows, but I'm not changing my vote regardless. --Adamant1 (talk) 00:13, 5 August 2023 (UTC)Reply[reply]
  •  Oppose. While I understand that IPs will create nonesense at times, the fact that IPs can create DRs is a net positive—we don't want people to abstain from nominating genuine copyright violations for deletion because of the hurdle of account creation, and the proportion of bad DRs created by IPs is not so bad as to require that we throw the baby out with the bathwater. — Red-tailed hawk (nest) 02:58, 8 August 2023 (UTC)Reply[reply]
    Yes, let’s file deletion requests for each and every of the soon 100 million files we host. I’m sure that would cover all of the bad ones which could be then deleted. It’s a really effective process. -- Tuválkin ✉ ✇ 12:46, 18 August 2023 (UTC)Reply[reply]
    Yeah...'cus that's a real issue that is happening. --Jonatan Svensson Glad (talk) 20:00, 21 August 2023 (UTC)Reply[reply]
    Sarcasm would look bad on you, as an admin — even had managed to do it properly. -- Tuválkin ✉ ✇ 00:27, 23 August 2023 (UTC)Reply[reply]
  •  Oppose, many IP editors nominate copyright violations for deletion, we shouldn't higher the bar to fight copyright violations. In fact, someone who has never made an account here might not even know that you could nominate a file for deletion if it wasn't explicitly stated like the "Nominate for deletion" button we have now, so removing that option would let a lot more copyright violations stay undetected for longer. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 18 August 2023 (UTC)Reply[reply]
  •  Strong oppose this would probable cause a spike in DMCA requests instead. Forcing someone register in order to request the deletion of a file is not furthering the goal of Wikimedia, nor would it be a great deterrent against bad DRs, simply a roadblock in the way of a potential good one - and I'd rather revert a bad DR than loose out on one goo one. --Jonatan Svensson Glad (talk) 19:57, 21 August 2023 (UTC)Reply[reply]
    You seriously think that a well meaning person with no prior knowledge of Commons’ inner workings and a good case for a file deletion would rather initiate a DR than ask for its deletion in the file’s talk page?… -- Tuválkin ✉ ✇ 15:36, 25 August 2023 (UTC)Reply[reply]

We clearly don't have consensus to change this, and I suggest we end the discussion rather than waste more time on it. Does anyone object? - Jmabel ! talk 01:56, 23 August 2023 (UTC)Reply[reply]

This discussion has attracted comments that are helpful to revisit the matter in the future — both points against allowing unlogged users to file Deletion Requests, and support for two very interesting conflicting notions:
  • omg IPs are people too!, therefore oppose
  • unlogged users are a bane indeed but they should be barred from all editing, not only DRs, therefore oppose
So, let this stay open for longer, please. -- Tuválkin ✉ ✇ 15:41, 25 August 2023 (UTC)Reply[reply]

Bad image list[edit]

Some wikis have bad image lists (MediaWiki:Bad image list) to prevent image vandalism showing on pages. Unfortunately, this is kind of useless because these lists generally cover only a small fraction of the images that could be used for vandalism. Often, the vandals will post close up images of genitalia. Is there some way to put all close up images of genitalia in a category so they could all be put on a bad image list en masse? Obviously this won't totally solve the problem, but I think this is what the bad image lists were intended to prevent and it's no longer working. Of course, it's not mandatory to block these images from showing, it would be up to the admins of each wiki. Kk.urban (talk) 19:13, 2 August 2023 (UTC)Reply[reply]

These categories already exist: Category:Close-up photographs of human penises and Category:Close-up photographs of human vulvas. You should not name such a list "Bad image list". This would be very offensive against the photographers and the subjects of the photo. The list could be called "Files used in vandalism context". GPSLeo (talk) 19:28, 2 August 2023 (UTC)Reply[reply]
No, that is a bad idea, as GPSLeo pointed out. There are a lot more images that vandals can use, including close-ups of human genitalia, therefore I believe that this would only be a fruitless attempt to address a much larger issue. 20 upper 14:24, 3 August 2023 (UTC)Reply[reply]
At least in some language versions, IP edits (including those from vandals) are not directly shown to most readers until they have been reviewed (Pending changes review) by community members, although everyone can request to see the latest non-reviewed version. This helps to combat vandalism. There are also anti-vandal bots which (afaik?) can detect and flag "bad" insertions from IPs and new users (such as insertions of "penis penis penis" in text form) so that human patrollers can remove those edits right away. Maybe the bots can be made more sophisticated to detect "bad" image insertions as well? Still, creating an exhaustive list of images that are "bad" is not something we should do on Commons. Creating bots smart+flexible enough to deal with bad-faith insertions is the task of bot-programmers. Also, here is one of the rare cases where I'd like to see semi-AI helping us. --Enyavar (talk) 15:42, 3 August 2023 (UTC)Reply[reply]
You are asking if it possible to create "general" filters for certain types of content? Commons is Not generally Censored, but given the direction certain jurisdictions are moving ( such as the United Kingdom, which wants online hosts to be circumspect about identifying legal but potentially harmful or offensive material.), a review of how 'bad' content is identified is warranted. There are also ethical and privacy concerns raised by hosting certain types of sensitive image, such as those of anatomical subjects. ShakespeareFan00 (talk) 08:54, 18 August 2023 (UTC)Reply[reply]
Commons is Not generally Censored General filters wouldn't be censorship anymore then the current practice of categorizing images based on if they have nudity or not is. Categorize just don't seem to work well for the purpose of hiding nudity. But it would be laughable to call putting an image showing people having sex in a sub-category specifically for those types of images censorship. Even though it technically serves to filter what kinds of images people are being exposed to. --Adamant1 (talk) 09:12, 18 August 2023 (UTC)Reply[reply]
No, we aren’t censored and the BIL on Enwiki is a last resort that comes with serious costs— namely I’d have to jump through bureaucratic hoops if I wanted to use an interesting, valuable file like File:Eveready Harton in Buried Treasure.ogv educationally on an article like w:The Good Old Naughty Days. We don’t need to force people to ask permission to use an anatomical image of a penis on their local article “human penis” Dronebogus (talk) 17:35, 30 August 2023 (UTC)Reply[reply]

Advanced upload stash[edit]

Dear community,

I know that we already have some sort of upload stah, but I have some ideas for a potential better one. I think about the possibility to upload for example up to 500 files in a private stash, that can only be accessed by the user itself. Once uploaded, the files can be equipped with information about source, author, and all the stuff. When filled in and done, the files can be published immediately or, as an extra feature, can be published on a desired date (up to 28 days in the future).

A temporarily private stash (for up to 28 days) would it make possible to upload first, and make sure that the files are on the server, and to fill in things later. Sometimes, some errors prevent publishing or a computer crash occur after the upload, but before the publishing, which can be really annoying when you already spent several minutes on filling out things, and all progress is lost. With my idea, the files and information (changes) before publication are saved in real-time (server-side), so you don't lose anything, and can publish them when you think you're done with all. What do you think? Greetings --PantheraLeo1359531 😺 (talk) 12:30, 4 August 2023 (UTC)Reply[reply]

Addendum: The files would be deleted 28 days after upload, so they won't be used as personal cloud storage --PantheraLeo1359531 😺 (talk) 12:31, 4 August 2023 (UTC)Reply[reply]
Currently, I only use the standard upload tools, where it can take an hour to upload just two dozen files, if you want to do it properly. So I am well aware of the benefits of such a change/addition, in general.
But as an alternative idea: I'd like to see a downloadable attribution tool so that frequent uploaders can pre-set licence/date/description(s)/categories on the local hard-drive, and then just upload when all preparations are done. As a bonus, such a tool wouldn't require a re-programming of the current user interface; and nobody would need to worry about new user namespace requirements, time limits, storage limits etc. --Enyavar (talk) 16:13, 9 August 2023 (UTC)Reply[reply]
@Enyavar: it can take an hour to upload just two dozen files: what is the speed of your Internet connection? How big are the files? (I ask because this is 5-10 times slower than what I experience from my usual setup). - Jmabel ! talk 17:37, 9 August 2023 (UTC)Reply[reply]
Typing takes time - for a number of literally 24 images, one hour means you finish describing+categorizing each file in under three minutes, which seems a lot faster than how I actually work. So apologies for exaggeration, I'm probably never that fast. If you only need 15-30 seconds (!?) per file, that probably means there's not much content or variation to describe in the first place. I even usually skip that unfriendly claims-tagging-interface in the final step, but I do try to compose meaningful descriptions for each file I upload, sometimes in multiple languages; possibly transcribe and even translate text; and find the most appropriate categories.
Yet, sometimes I find my computer lost internet connection somewhere along the way, critically right when I finally submit the finished uploads --> that is an hour potentially gone to the drain, although I found workarounds to prevent that. Among others, a golden rule to never try to upload more than ~10 images in one go. The upload-process is well-designed, no doubt, but a stable internet connection throughout the process chain is required.
The uploader's idea is "first upload in one fell swoop, then finish the descriptions+categories in a private space so that the images are already safe on the server". My counter-proposal was "be enabled to describe+categorize on the local PC first, then upload in one fell swoop". --Enyavar (talk) 19:15, 9 August 2023 (UTC)Reply[reply]
@Enyavar: Right, I thought your remark was about upload speed. I was talking only about the speed of uploading numerous files of essentially the same subject matter (e.g. images of a particular parade). - Jmabel ! talk 20:42, 9 August 2023 (UTC)Reply[reply]
unfriendly claims-tagging-interface I take it you are using the Upload Wizard. I avoid it like the plague. I just ping-pong between two tabs and use Special:Upload. I copy-paste wikitext from one photo to the next, and make the necessary edits each time. Low risk (at worst, in the rare case of failure, it's one photo at the time) and from what I can tell, much faster. - Jmabel ! talk 20:42, 9 August 2023 (UTC)Reply[reply]
Same here, exactly. -- Tuválkin ✉ ✇ 15:45, 25 August 2023 (UTC)Reply[reply]
@Enyavar: There are several bots or automated tools which work that way. See COM:Upload tools. Yann (talk) 20:45, 9 August 2023 (UTC)Reply[reply]
At least personally a lot of my uploads take a long time to finish and often fail halfway through the process. That's with Spectrum in a fairly urban area to. So they really need to implement the ability to resume failed uploads or something. Honestly, I'm kind of surprised they don't have the feature already. --Adamant1 (talk) 04:47, 13 August 2023 (UTC)Reply[reply]
 Support we need sth better but without having to download third party apps.
uploading files to wmf servers and preparing the file descriptions are two separate tasks. with the current upload form/wizard, 1st task must be done without disconnecting, but the 2nd task is something that can be done even if connection is intermittent. but now we can only do the 2nd after we have done the 1st (but before clicking the final submit button). when a lot of files are batch uploaded, if we want to avoid problems occurring when we slowly fill up the file descriptions, in other words we have to finish the descriptions quickly, there's only 1 way under the current wizard design: giving very basic filenames and descriptions, and only go back to edit after we have successfully submitted the uploads. RZuo (talk) 16:32, 28 August 2023 (UTC)Reply[reply]
@RZuo: Have you tried drafting the file description page locally and then uploading with our upload form for experienced users and copy/paste?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:54, 30 August 2023 (UTC)Reply[reply]

Limit file overwriting to users with autopatrol rights[edit]

There are many disputes on overwriting of files and also many cases of long undiscovered bad overwrites. To prevent this I would propose that file overwriting is only allowed to users with autopatrol rights. Users without autopatrol rights should remain to be able to overwrite their own files. This simple change would prevent a lot of time consuming disputes. As the requirements to get autopatrol rights are low this would not prevent users from doing useful contributions. GPSLeo (talk) 07:31, 13 August 2023 (UTC)Reply[reply]

I may support this, but could we start this with an edit filter/tag to determine how widespread this activity is, and perhaps stave off some of those "undiscovered" mistakes? Elizium23 (talk) 07:45, 13 August 2023 (UTC)Reply[reply]
Elizium is right, out of the blue I have no indicator how often overwrite actions by non-autopatrollers happen at all, and how often this turns out to be an undiserable action. Also, can this be tagged/filtered retro-actively?Enyavar (talk) 10:15, 13 August 2023 (UTC)Reply[reply]
Checking how often this happened in the past is a bit complicated. But I create an abuse filter to monitor all cases from now on Special:AbuseFilter/290. GPSLeo (talk) 10:51, 13 August 2023 (UTC)Reply[reply]
I had a look at the filter hits: Since yesterday 19:00 UTC there were 74 files overwritten by users without autopatrol rights. I had a look at all these edits. 20 of the overwrites are fine. In 20 cases it could be discussed if the overwrite violates the guideline. In 34 cases there is a clear violation of the COM:OW guideline. GPSLeo (talk) 09:45, 18 August 2023 (UTC)Reply[reply]
  •  Support --A.Savin 09:22, 19 August 2023 (UTC)Reply[reply]
  •  Support I would even support if only the authors, admins, people with (a new) overwrite right or specially marked images (maps or similar) were allowed to overwrite them. --XRay 💬 10:00, 19 August 2023 (UTC)Reply[reply]
    For this we could create a filter to mark the edits. GPSLeo (talk) 11:06, 19 August 2023 (UTC)Reply[reply]
 Support I agree with XRay but in any case new users don’t have any good reason to be trusted with such a powerful potential vandalism tool Dronebogus (talk) 03:39, 20 August 2023 (UTC)Reply[reply]
  •  Question: in cases where non-autopatrolled users have legit reasons for overwriting, how do you envision they submit an overwrite request in the future? --HyperGaruda (talk) 05:41, 20 August 2023 (UTC)Reply[reply]
    They should just request autopatrol rights. I do not think that there are cases where a user is trustworthy for overwriting but not for autopatrol rights. Alternatively we could create a template that can only be placed by admins/patrollers to make an exception for a file. GPSLeo (talk) 15:55, 21 August 2023 (UTC)Reply[reply]
 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:56, 26 August 2023 (UTC)Reply[reply]
 Support - A great idea. Nosferattus (talk) 06:24, 27 August 2023 (UTC)Reply[reply]
if a user is denied autopatrol but the overwrite request is justified, how are you gonna process that request?--RZuo (talk) 14:42, 27 August 2023 (UTC)Reply[reply]
  •  Weak oppose. I'm not sure if this is such a good idea. It seems like it will fundamentally change editing unless you're one of a small group of editors. I have overwritten a decent number of files, for things like SVG code cleanups. I only got autopatrolled because I asked for it when I needed to upload and MP3 file. But on the other hand, the rate of misuse by well-intentioned editors seems to be high. But could making greater efforts to educate newer users of when to overwrite files be the better approach? Edit: There are also files that need to stay updated, like File:Gestational limits for elective abortion in the United States.svg, which I could not have worked on unless I was autopatrolled or someone allowed uploads by all. The Quirky Kitty (talk) 08:23, 14 September 2023 (UTC)Reply[reply]
  •  Comment - First (1st) of all, having seen a large amount of problematic overwrites by new and sock accounts I acknowledge that this is a major problem and a common cause for edit warring. However, there are plenty of legitimate cases where users who very likely aren't eligible for autopatrol will run into problems if they cannot overwrite a file. At the Graphics Lab there are a fairly number of WikiGraphists with no user rights that upload high quality SVG files, many of these users barely have any uploads and edits in general but the few edits they have consists of taking on requests and / or cleaning up SVG source codes (something which can only be done by overwriting files). Another issue is that if non-autopatrolled users can't overwrite their own files they might upload a similar file and then request deletion for the original, minor cropping or censoring faces, license plates, Etc. for privacy reasons are common examples here. Further regarding SVG files we could see situations where users will upload nearly identical SVG or even identically looking SVG files and then nominating the original for deletion over errors in the code ("Bad code") or over minor colouring issues that could've easily been fixed by overwriting.
There are a number of unforseen consequences that I simply haven't seen anyone bring up here. Perhaps if such a filter is put in force it should exclude users overwriting their own files. We don't want a vandal replacing a highly visible picture of the Louvre with their penis or vagina, but also don't want to limit technically skilled users with barely any contributions from cleaning up SVG source code. The issue with the latter is that SVG files are the files that are most likely to be overwritten, edit warred over, and vandalised, so excluding them wouldn't make much sense either. If technically feasible we should limit new users overwriting files uploaded by others (namely users who aren't currently a part of a file's upload history), but we should also find a way to allow users without Autopatrol right to help with improving them. Sometimes non-Autopatrolled WikiGraphists overwrite a current coat of arms with a better version because the current one has a minor factual error. A look at "File:Flag of the Vatican City.svg" shows how many trusted Wikipedians without Autopatrol rights helped improve this image. Personally, I'd say that the best solution that would take the least time and introduce the least unnecessary workload would simply having a daily list of overwritten files by non-autopatrolled users showing the previous iteration of the file and the new iteration. I'm fine with a template to allow overwriting, but it would also be a lot of work to manually add them to uploads where they should be allowed. As this has already passed I'm only adding suggestions as this will affect flags and coats of arms which are commonly overwritten by Wikipedians with barely any Commonswiki edits.
Another issue is that users cannot show with which files they would like to overwrite without separately uploading them creating needless duplicates or even making overwriting the original more difficult because of duplicates. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:54, 10 September 2023 (UTC)Reply[reply]

Implementation problem[edit]

There is a clear consensus to limit the file overwriting. I tested the implementation and ran into a problem. The limitation itself is no problem and could be turned on at any time by switching the abuse filter to blocking. But there is problem with allowing particular files. My idea was to make the template {{Allow Overwriting}} that can only be placed by users with patrol rights and the make an exception for all files with this template on the file page. The problem is that there is no way to check the wikitext of the file page when a file upload is logged. So it seems that we would need a new user right and protection level to get the ability to make exceptions of particular files. Writing all exceptions into the abuse filter is not practical.(For the low amount of test files this is no problem.) As the solution for the exceptions might take a while do we want to implement the limitation without the ability for exceptions for now? --GPSLeo (talk) 15:23, 31 August 2023 (UTC)Reply[reply]

Ping at @P199, Krd, Glrx, A.Savin, XRay, Dronebogus, Tuvalkin, Jeff G., Nosferattus, and C1K98V: are you fine that we wait for a response on the bug report
Tracked in Phabricator
Task T345896
. Then if the problem can not be fixed that fast we implement this despite the problem that exceptions are only possible if they are written directly into the abuse filter? GPSLeo (talk) 09:24, 8 September 2023 (UTC)Reply[reply]
Yes --A.Savin 09:50, 8 September 2023 (UTC)Reply[reply]
Yes, Thanks. C1K98V (💬 ✒️ 📂) 10:09, 8 September 2023 (UTC)Reply[reply]
Sure. --XRay 💬 11:47, 8 September 2023 (UTC)Reply[reply]
Of course, yes. -- Tuválkin ✉ ✇ 13:08, 8 September 2023 (UTC)Reply[reply]
Yes, BTW, the bug link isn't working for me. Nosferattus (talk) 17:26, 8 September 2023 (UTC)Reply[reply]
@Nosferattus: That was fixed by GPSLeo in this edit to reference phab:T345896.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:39, 10 September 2023 (UTC)Reply[reply]
OK as long as new user can overwrite his own uploads. Glrx (talk) 18:23, 8 September 2023 (UTC)Reply[reply]
@GPSLeo: What would the filter rules be until phab:T345896 is resolved?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:42, 10 September 2023 (UTC)Reply[reply]

Creation of a new mega-category for promoting images/files that go against stereotypes, explains history facts and/or are schocking in some way[edit]

No consensus to make any changes based on this proposal. The Squirrel Conspiracy (talk) 16:52, 8 September 2023 (UTC)Reply[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hi everyone.

I'm a user that started to contribute first on the italian Wikipedia at the end of 2021 and then on Commons at the beginning of this year. I'm mainly contributing here for now uploading all the available photo about the Romanov imperial dinasty and other historical things.

Navigating through many historical (and not only) photographs here on Commons in these months, I noticed various images that are very schocking and disrupting in the way them cancel many stereotypes and have the ability to describe in a very straightforward way something that otherwise would be difficult to explain or remember. Those images has the power to describe some historical thing or fact in an incredible simple way, I think.

I think that it should be a primary task for Commons to fight all the stereotypes possible... and photographs may be the best way for doing it succesfully.


We already have 3 categories for promoting photos here in Commons:

- Featured pictures (great images from skilled creators)

- Quality images (great/well composed images from Commons users)

- Valued images (good images promoted for being used in other Wikimedia projects, being the best representation of a particular subject)


Well, ladies and gentleman... i propose the new mega-promotion-category Unique images (or Unusual images, etc.), and I can already make some interesting example...

...and there would be many others ready!

We have an extraordinary historical archive here on Commons and many of those photos are not even included in some Wikipedia/Wikimedia pages, imaging having them promoted in some way!

No one sees them, no one knows about them and the things that they describe... it's like those photos aren't existing at all! Entire huge archives from single authors or from national archives from all over the world are being progressively stored here on Commons... we just CAN'T let all this be forgotten, continuing to insert on Wikipedia pages always the same, ultra-known historical dozens of stereotyped photos already written in all the school books.

I already know there's the "FP/Historical" promotion-subcategory, but it somehow isn't good enoughf, not by far (and being that category without any other subcat., despite all the others, make you realise by yourself the GREAT problem we have...).

This is my proposal, from my humble position and opinion... it is an idea, that somehow need to be realised.

Remember what I'm saying now to you: here in Italy quite the entire nation lives on false stereotypes of all kind that is pushing the ENTIRE politic system make the worst errors of all sorts and in every sector

Just to let you know what stereotypes can do...

Thank you for your attention. LucaLindholm (talk) 02:53, 24 August 2023 (UTC)Reply[reply]

These are extremely subjective criteria, and the inclusion of images would be based on what? Any uploader's personal judgement? enwiki has a List of unusual articles which is kept for humor's sake, but is likewise subjective, and by no means systematic. Elizium23 (talk) 04:33, 24 August 2023 (UTC)Reply[reply]
+2. I'm not sure why "FP/Historical" couldn't feature images important to the history of social justice movements, but unique images is to subjective. The same goes for images that break stereotypes. --Adamant1 (talk) 04:58, 24 August 2023 (UTC)Reply[reply]
@Adamant1 @Elizium23
Well, even the 3 top categories could be subjective... and, as a matter of fact, images are added to them by request from someone and community vote. It has always been in that way. LucaLindholm (talk) 21:56, 24 August 2023 (UTC)Reply[reply]
All of those categories include an elaborate process of nominating, voting, etc. I doubt there is the interest to get together a group of people to work on doing this in that manner, but if you have a group of roughly a dozen or more people who would want to work on this, and intend to extablish criteria, define a process of selection and participate actively, that might be a good thing. But that's a long way from just creating a category. - Jmabel ! talk 22:44, 24 August 2023 (UTC)Reply[reply]
I have to say, though: I'm not encouraged by finding none of the images you've given as examples particularly interesting, which shows how subjective this is. - Jmabel ! talk 22:46, 24 August 2023 (UTC)Reply[reply]
File:Lowell Mars channels.jpg Yes, it can be difficult to decide which pictures belong in these categories. You might want to start by making three lists of a few hundred of the most anti-stereotype, the most explanatory of history facts, and the ones that most shock you. For example, this picture shocked some people when it was new but other people might not think so. Jim.henderson (talk) 00:27, 25 August 2023 (UTC)Reply[reply]
Commons:Categories for discussion/2022/08/Category:Commons' weirdest photographs Commons:Categories for discussion/2021/05/Category:Cursed images.
i say this proposal can be closed.--RZuo (talk) 14:42, 27 August 2023 (UTC)Reply[reply]
Mmh... the fact that this continues to be proposed over time something says however... and for us users that love to browser the endless historical photos archive on this project, it is a thing somehow felt as important. We should think at it, maybe by putting some precise requirement in order to accept them. That's a thaught. LucaLindholm (talk) 22:36, 27 August 2023 (UTC)Reply[reply]

This seems much more suitable for a gallery page, than a category. Even there, it seems a bit subjective; it might really be just a subpage of a user page. - Jmabel ! talk 15:53, 24 August 2023 (UTC)Reply[reply]

  • I have no idea what this proposal is suggesting. The criteria don’t make any sense. Dronebogus (talk) 17:27, 30 August 2023 (UTC)Reply[reply]


The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

MP4 and MKV videos[edit]

Good night! I have a suggestion to upload video files with MKV and MPEG4 codec, which in turn will save participants from having to convert videos to lower formats. MasterRus21thCentury (talk) 22:18, 25 August 2023 (UTC)Reply[reply]

We only allow file types that are not patent encumbered. —Justin (koavf)❤T☮C☺M☯ 07:49, 26 August 2023 (UTC)Reply[reply]
 Oppose per Justin.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:14, 26 August 2023 (UTC)Reply[reply]
Wouldn't MP4 be automatically accepted once the parents expire or would that need another discussion to "reach consensus"? As the only reason I can find for its exclusion is the patents. In fact, it might be wise for the Wikimedia Commons to just automatically accept any and all formats for files (unless all files in that format are automatically out of scope, like .TXT files) the moment there are no intellectual property issues, that would save the community a lot of time with these endless decades long discussions over formats. We simply block formats if they prove disruptive and allow them all by default (again, as long as there are no IP issues as there currently are with .MP4 files.). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:56, 31 August 2023 (UTC)Reply[reply]
MP4 containers nowadays are usually used to transfer AVC (H264) or HEVC (H265) video, not MPEG4; the patents on AVC don't expire for a few years still, and HEVC for quite some time. Omphalographer (talk) 17:14, 31 August 2023 (UTC)Reply[reply]
Exactly this ^^^^^ —TheDJ (talk • contribs) 18:33, 8 September 2023 (UTC)Reply[reply]
At the end of this year, will we have a way to accept MP4 files but reject ones with AVC (H264), HEVC (H265), or other patent-encumbered codecs?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:46, 10 September 2023 (UTC)Reply[reply]
Same question re MKV.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:48, 10 September 2023 (UTC)Reply[reply]

Adding OpenEXR (EXR) to the list of allowed filetypes on Commons[edit]

Hi folks!

While searching for files, I often found the EXR filetype. I am wondering because the filetype is not allowed on Commons (yet).

Because of this, I want to ask, or suggest to add EXR to the allowed filetypes. OpenEXR is an open filetype especially for images with high color depth (and HDR). The filetype is suitable for panoramics (up to 32 bits per channel) and high quality textures (for meshes etc.). See for more information: https://en.wikipedia.org/wiki/OpenEXR

What do you think?

Greetings, --PantheraLeo1359531 😺 (talk) 15:14, 28 August 2023 (UTC)Reply[reply]

My understanding is that this format is primarily intended for use as an intermediate format in film production. Can you give any examples of how it could be used in Commons, particularly given that it is not supported by web browsers? Omphalographer (talk) 02:43, 31 August 2023 (UTC)Reply[reply]
The advantages are saving in up to 32 bits per channel for HDR photographs (especially panoramas), it can be read by many image viewers and can save many layers and several channels (also z-buffer afaik). It is also common in assets for computer games or to save raster images with many different information that are rendered or generated by computer software. So it is used in professional production of media, 3D scenes or other professional rendering and CGI (VFX, etc.) --PantheraLeo1359531 😺 (talk) 15:55, 31 August 2023 (UTC)Reply[reply]
This also possible with the widely used TIFF. If that has not enough information we should get support for DNG. GPSLeo (talk) 16:28, 31 August 2023 (UTC)Reply[reply]
It seems like EXR saves far more disk space than TIFF --PantheraLeo1359531 😺 (talk) 12:02, 1 September 2023 (UTC)Reply[reply]
If you use some compression TIFF files can also be very small. GPSLeo (talk) 13:45, 1 September 2023 (UTC)Reply[reply]
As far as I'm concerned, "you can also do that with A" is not a convincing argument against supporting B. El Grafo (talk) 10:09, 8 September 2023 (UTC)Reply[reply]

New display field in every page DEFAULTSORT[edit]

Would it be possible to display the DEFAULTSORT value on an item's page? This would avoid having to edit the page to see it JotaCartas (talk) 08:23, 9 September 2023 (UTC)Reply[reply]

About saving files in the editing view[edit]

I'm from the Finnish Wikipedia. I have noticed that some new and inexperienced users have uploaded copyrighted images from the edit view. Is it possible to see from somewhere how many such uploads have taken place? At least Kyykaarme has made some sort of list of such[1][2][3]. You can also see such cases in my edits and logs when I have suggested such images to be removed. If you think there are so many such uploads, could that function be limited to a certain user access level or removed completely (at least in the Finnish Wikipedia, because I don't know about other Wikipedias)? Luurankosoturi (talk) 09:12, 11 September 2023 (UTC)Reply[reply]

@Luurankosoturi: Per mw:Upload dialog#Configuration (for wiki sysadmins), "Starting with MediaWiki 1.28 (but not 1.27), it can be disabled by setting $wgForeignUploadTargets to []" (no translation to Finnish yet). Finnish Wikipedia is at MediaWiki Version 1.41.0-wmf.25 (a7ea3a3) dated 21:18, 4 September 2023. You are welcome to form a consensus for such a change on Finnish Wikipedia. We currently have a total of 1,660,170 cross-wiki uploads listed in Recent Changes per Special:Tags (not just from Finnish Wikipedia). It may also be possible to limit cross-wiki uploads by Finnish Wikipedia users here on Commons to autopatrolled users here using Special:AbuseFilter/153 or another filter.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:53, 11 September 2023 (UTC)Reply[reply]

How about a gadget License-a-lot similar like cat-a-lot[edit]

I have been involved licensing and noticed in some artist categories it would be really helpful to have a tool where one can add a license to multiple files. It would also be helpful for files missing a FOP license etc.Paradise Chronicle (talk) 11:21, 13 September 2023 (UTC)Reply[reply]

The FOP templates like {{FoP-Germany}} are just hints and no required licenses. Real license changes are very rarely and if needed Visual File Change should be sufficient for this. A tool that makes license changes very easy could also be misused. GPSLeo (talk) 14:15, 13 September 2023 (UTC)Reply[reply]
Though, really, this is pretty easy with VFC. - Jmabel ! talk 15:28, 13 September 2023 (UTC)Reply[reply]
I didn't know about the VFC, good to know. But it's not so easy, I tried it right after I saw your reply, but eventually didn't hit the proceed button. I was using Vector 2022 skin and I believe the description is for the Vector 2010. Will read and try some more.Paradise Chronicle (talk) 05:00, 14 September 2023 (UTC)Reply[reply]
Hi, as long as you're not on a mobile device: Maybe just do yourself a favor and switch to Vector 2010? On the topic however, I can't imagine how a lic-a-lot would work, because you can't see which licenses would be appropriate from a category page. Using VFC sounds like the best workaround even though it's less easy to use compared to cat-a-lot. --Enyavar (talk) 08:51, 18 September 2023 (UTC)Reply[reply]
Hi @Enyavar, thanks for the little push, I was a bit unsure before, but now I tried it with three smaller categories and I believe it worked. Thanks very prominently to @Jmabel. I am still practicing and will try it at a larger category later. Paradise Chronicle (talk) 10:39, 18 September 2023 (UTC)Reply[reply]
That the FoP licenses are just hints isn't really well known. Several series of my uploaded files (from monuments publicly accessible) were marked as derivative works some even with a FoP license from Switzerland. In the end, experience showed that if I add a FoP license to the relevant files, the files can stay. I know at least one editor who uploaded numerous files without adding a FoP license. Thats why I thought adding FoP licenses (to for example monuments in Switzerland) would be quite helpful. Paradise Chronicle (talk) 18:07, 17 September 2023 (UTC)Reply[reply]
The FoP templates are not licenses. They are simply statements about how copyright law works in certain countries. - Jmabel ! talk 22:13, 17 September 2023 (UTC)Reply[reply]

Allow UTRS on commons.[edit]

Blocked Commons editors with their talk page access revoked cannot usually appeal their block easily, (they could email an admin for help, but that is rarely considered) enwiki already has UTRS, why can't this be extended to commons as well? --Grandmaster Huon (talk) 17:07, 14 September 2023 (UTC) Grandmaster Huon (talk) 17:07, 14 September 2023 (UTC)Reply[reply]

  •  Strong support, by default it should exist. Even if it's not going to be frequently used, there should at least be an option for users who wish to be able to return in good faith to be able to do so if they otherwise can't do this on-wiki. Per "Commons:Blocking policy": "blocking is designed to be a preventative measure and not a punitive one". Any admin that wishes to spend their time there can, any admin that doesn't want to doesn't have to, it's an opt-in system that will only add more options. My main issue with the UTRS is that it's all "behind closed doors", by default the bot that places the template on the blocked user's talk page should also include the entire message unless they themselves have selected to not want this to be publicly posted and the response should also be posted publicly on the talk page (after review by UTRS agent to prevent trolling). The only exceptions should be in cases where privacy is indeed something to be protected. Once TPA is revoked a standard template with information about unblocking, what the user needs to understand, and at the very bottom a link to the UTRS should be provided, obviously UTRS agents can revoke UTRS access like they already can at the English-language Wikipedia. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:24, 14 September 2023 (UTC)Reply[reply]
 Addendum, I'd like to provide the case of user "ARichardMalcolm" (he had to message on enwiki) who wanted to donate materials related to his book and "05:40, 15 July 2016 INeverCry talk contribs blocked ARichardMalcolm talk contribs with an expiration time of indefinite (account creation blocked, email disabled, cannot edit own talk page) (promotion-only account)" which was undone later "15:37, 9 November 2017 Guanaco talk contribs unblocked ARichardMalcolm talk contribs (Inappropriately blocked by INC with talk page access disabled; user appears to be reasonable, and any issues can be discussed with them)", many users or companies that wish to donate their materials get nuked and have their talk and e-mail access disabled, there literally is currently no appeals process. Every single productive user who could've been unblocked had they understood the rules and isn't planning on being disruptive is one too many. Blocks exist to prevent further disruption, people who want to cause more disruption tend to ignore blocks and will continue disrupting through socking, but at what point does someone become "a lost cause" and why should this only be at the digression of a single admin that decides that there should be no possible road to unblock? In fact, the current system encourages socking as user "Mutter Erde" had to sock to evade a block they couldn't appeal and they returned now as a productive member of the Wikimedia Commons community. Simply having a UTRS will solve a lot of problems and it's an opt-in system no current admin is forced to use unless they choose to. My only issue with it is that it's a closed off system and matters concerning the Wikimedia Commons should best be discussed on-wiki and not off-wiki, but we simply don't know how many users want to return as productive members but can't because they don't want to break the rules by socking and have just given up on appealing their blocks, this simply seems like a more likely scenario. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:36, 15 September 2023 (UTC)Reply[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --From Hill To Shore (talk) 11:40, 20 September 2023 (UTC)Reply[reply]

Tracking file usage on the AARoads Wiki[edit]

On Commons talk:Tracking external file usage I've proposed that Usage Bot should start maintaining a set of galleries tracking the usage of Commons' files on the AARoads Wiki like it does for several other external wikis. Opinions on this proposal should be posted there. --bjh21 (talk) 21:29, 14 September 2023 (UTC)Reply[reply]

Shutdown of Computer-aided tagging: Mass revert?[edit]

After the WMF team evaluated the quality of edits made through the Computer-aided tagging tool they decided to shut it down.

Tracked in Phabricator
Task T339902

With this there is also the question if we want to revert all edits made through the tool. This would affect one and a half million edits made through the tool. We could except edits made by users with autopatrol rights from the revert to reduce the amount of potential good edits getting lost in the revert. GPSLeo (talk) 12:49, 16 September 2023 (UTC)Reply[reply]

I come across these mistakes very frequently. And the bot tags are completely inaccurate. When I look at the file's history, no one but the bot has edited it. What the solution is, I do not know, but I belief is that the Commons has been massively harmed by bot tagging. Krok6kola (talk) 15:25, 16 September 2023 (UTC)Reply[reply]
The WMF classed 73.4% of such values as "bad". Absent an alternative proposal, I think this is inevitable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 16 September 2023 (UTC)Reply[reply]
If we mass revert, then the bot should leave an edit summary that encourages anyone watching the file to check to see if what it has reverted should be restored. After all, 26.6% of 1.5 million is not small. If they are right in their count, we would be having a bot revert about 400,000 good edits to get rid of 1.1 million bad ones. (BTW, I think the numbers are a bit misleading, because thousands of these edits were things like two people edit warring over the depicts on a file.) - Jmabel ! talk 17:14, 16 September 2023 (UTC)Reply[reply]
Do you refer to the ISA tool disaster? These edits are not marked as done with Computer-aided tagging. We should only include edits with the "computer-aided-tagging" tag, the ones with "computer-aided-tagging-manual" tag should also not be included. GPSLeo (talk) 17:22, 16 September 2023 (UTC)Reply[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=803479629"