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

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?

 
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. 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)TCM 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]

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.

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

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.

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]
 Support Good idea. Yann (talk) 15:19, 23 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 . 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]

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]

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.

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]
I doubt that any such edit wars were tagged as being by the Computer-aided tagging tool, so they won't be included in the figure given. Do you have any examples to the contrary? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:53, 23 September 2023 (UTC)Reply[reply]
  • Support bulk revert. Up to a simple bulk deletion of everything, if we have no better way to separate out the trash. Yes, it's that bad. Andy Dingley (talk) 15:01, 23 September 2023 (UTC)Reply[reply]
  •  Support I don't see any other way. Of course, the bot reverting the tags should leave a proper entry in the history. --Robert Flogaus-Faust (talk) 15:08, 23 September 2023 (UTC)Reply[reply]
 Comment - It would be worth of save the added values to file or something before bulk reverting them so if somebody would like try to filter out useful ones (using machine vision for example) I think something like open_clip could work for finding useful tags and I could could do a practical test if the idea works at october. --Zache (talk) 18:28, 23 September 2023 (UTC)Reply[reply]
 Support bulk revert.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 13:49, 24 September 2023 (UTC)Reply[reply]
 Comment has anyone asked the tech team to share the list of what they determined to be "good" edits so we can assay whether it looks like there would be a fair amount worth keeping? But I wouldn't object to just deleting it all. One ham-handed mass edit deserves another.
Edit summary should make clear that this is "without prejudice" and if you think the item was correct you should feel free to re-add. - Jmabel ! talk 15:58, 24 September 2023 (UTC)Reply[reply]
The criteria are detailed in the linked Phabricator ticket. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 24 September 2023 (UTC)Reply[reply]
 Support (with an appropriate edit summary that encourages people to re-revert bad reverts) El Grafo (talk) 14:43, 2 October 2023 (UTC)Reply[reply]

Filter for files used on Wikimedia sites[edit]

I hope all well. Would it be possible to add a filter that allows you to see all images you've uploaded that are currently used on other Wikimedia sites/pages? Unlike the "File usage on Commons" section, it would show every file used (which could be further filtered to only include specific Wikimedia sites). Apologies if this already exists, but I was unable to find it. Have a great day! DiscoA340 (talk) 20:34, 24 September 2023 (UTC)Reply[reply]

@DiscoA340: Hi, and welcome. GLAMorous should help you get started with finding uses of your uploads on WMF projects. It contains various checkboxes for use in refining your research.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 20:39, 24 September 2023 (UTC)Reply[reply]
@Jeff G. Many thanks! I thought something like that should exist but I couldn't find it. Thanks and have a great day! DiscoA340 (talk) 20:51, 24 September 2023 (UTC)Reply[reply]
@DiscoA340: You're welcome!   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 20:55, 24 September 2023 (UTC)Reply[reply]

Unified license for government websites of Ukraine[edit]

Recently, when visiting government websites of Ukraine, almost everywhere at the bottom of the pages you can find the following description: All site materials are available under a Creative Commons Attribution 4.0 International license, unless otherwise noted. Is Wikimedia Commons required to have a single template for sites with the gov.ua domain, while the list of resources will be clearly monitored by administrators? MasterRus21thCentury (talk) 18:27, 4 October 2023 (UTC)Reply[reply]

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

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)Reply[reply]

This has already been requested multiple times, but till now the WMF team did not work on a solution for the current technical limitations. GPSLeo (talk) 18:19, 9 October 2023 (UTC)Reply[reply]
Thank you for mentioning, I hope this issue will be served soon :) --PantheraLeo1359531 😺 (talk) 20:21, 9 October 2023 (UTC)Reply[reply]