Commons:Village pump/Proposals

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/2022/04.

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?

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

Suggestions at File license templateEdit

The template {{File license}} still suggests to use {{self|GFDL|cc-by-sa-all}} or {{PD-self}}. As GFDL as single license is not allowed anymore and there are good reasons for using the current 4.0 CC licenses only I think we should change this suggestion to {{Cc-by-sa-4.0}}. As CC0 has many benefits over PD-self we should change this suggestion too. --GPSLeo (talk) 16:57, 13 April 2022 (UTC)

Agree with suggesting CC0 instead of PD-self. But multilicensing with GFDL and CC-BY-SA is more flexible than just CC-BY-SA. The suggestion is to license with all versions too, not just 4.0, making the suggestion more flexible still. I don't see any good reason to change that. Carl Lindberg (talk) 17:37, 13 April 2022 (UTC)
How do the -SA licences work with versions and derived works? Can you combine a -SA 2.0 with a 4.0? Does this make all of it 4.0? If so, specifying 4.0 will not hinder that combination, but does hinder licencing the derived work as 2.0. This might be a reason to do so, if we regard 2.0 as flawed. Of course, it helps with reuseability, especially in the case where a reuser has settled on a specific version (e.g. to minimise needed lawyer time). –LPfi (talk) 11:51, 24 April 2022 (UTC)
Other than 1.0, you can license to the later -SA version. So if you have a 2.0 and a 4.0 work, you can make a derivative of both only under 4.0. But if the 4.0 is multi licensed to all versions, then you can choose 2, 3, or 4, depending on what you want. Even if we think there is no good reason to do so, maybe someone else thinks differently, or maybe a future version will have some consequences some users don't want. Or, maybe there is a site out there which uses e.g. 3.0 for all their stuff; that makes 4.0 works difficult to incorporate. It's all theoretical of course, and not usually a problem, but unless there is something specific we don't like about older licenses, it really can only help. Flickr still uses 2.0 for example; if you want to make a derivative work and post it on Flickr you really can't unless the underlying work also allows 2.0. As for GFDL, it is not compatible with CC-BY-SA so you can't combine those works, unless one of them you can argue fair use or de minimis etc. I think the 3.0 versions are one-way compatible with GPLv3 (you can put CC-BY-SA-4.0 works into GPLv3 projects, but not vice versa). Carl Lindberg (talk) 14:50, 16 May 2022 (UTC)
I agree with Carl: we should suggest CC0, but there's nothing obviously wrong with the current multi-licensing suggestion. While there are ways of combining works with multiple copyleft licences, they're hard to understand and implement. Multi-licensing avoids those problems. --bjh21 (talk) 12:14, 16 May 2022 (UTC)

Proposed move of everything in Category:Borodianka Raion to Category:Bucha RaionEdit

Borodianka Raion no longer exists, as it was merged into Bucha Raion in 2020. To keep up to date, I propose that all images, category pages, etc. all the way down the category and naming hierarchy, referring to Borodianka Raion should be moved to refer to Bucha Raion. The Anome (talk) 10:14, 24 April 2022 (UTC)

I think the correct place to discuss this is COM:CFD not VPP. Hulged (talk) 10:46, 24 April 2022 (UTC)
It also isn't obvious that we should use official regions. If we merge categories and depicted location is partly documented by the category, we loose information if we replace the category by a broader one. If the old raion still makes sense as a geographic entity, although not an administrative one any more, it should rather be made a subcategory. There was this kind of problems when a host of municipalities were merged in south-western Finland: e.g. "Själö (Nagu)" was changed into "Själö (Pargas)", despite there being at least two Själös in the new Pargas. Also Category:Buildings in Pargas lost much of its information value, when buildings from elsewhere were moved there because of the merger. –LPfi (talk) 11:42, 24 April 2022 (UTC)
You could also use the old region for 1923-2020 when it existed and the new one for post-2020 images. Either way, this belongs at COM:CFD for greater discussion. -- Ricky81682 (talk) 02:42, 10 May 2022 (UTC)

Add glTF file support/previewEdit

glTF is a relatively new 3d model file format that is supported by widely used 3d frameworks like three.js. As it's on high demand, there are tons of websites providing free glTF models. It would make a nice addition to have it on commons. --Comrade-yutyo (talk) 13:37, 29 April 2022 (UTC)

Use VRTS for OSEdit

Currently oversight request is processed over mailman, and this proposal aims to migrate it to VRTS system. Some issues related to current process:

  • Sender need to use "reply all" function to make a copy inside mailing list (rather than only send to a specific oversighter);
  • Some system message (some text appended or something else generated by mailman) seems not user-friendly;
  • Beneficial if user sent request to the wrong position;
  • More efficient if action require information only visible to oversighters;
  • And of course, powerful boilerplate (also one of the biggest advantages for VRTS).

Anyway, I just found no reason block this. Thanks. Stang 20:27, 29 April 2022 (UTC)

The English Wikipedia switched over about a decade ago and it has been smooth -- Guerillero Parlez Moi 20:04, 3 May 2022 (UTC)
Invite current OSer for discussion @Odder, PierreSelim, Rama, and Raymond: . Stang 18:20, 7 May 2022 (UTC)
I might still be banned from VRTS, so it's a "no" from me. odder (talk) 21:50, 7 May 2022 (UTC)
Is there something broken with the current way of doing, if no there is no reason to change. OTRS/VRTS does not seem really useful for the low volume of request sent to the oversighter by emails. --PierreSelim (talk) 15:38, 11 May 2022 (UTC)

Allowing index to gallery subpages in main namespaceEdit

I have uploaded many pictures from an old album about China with pictures taken by the Japanese. They were displayed in gallery pages for each volume in亜細亜大観/01, 亜細亜大観/02, 亜細亜大観/03... I have also created an index to the pages 亜細亜大観 to link to the sub pages and was deleted because it's a "Gallery page without at least two images or other media files". Then how should I share the album? I think index to gallery subpages should be allowed. An analogy is Wikisource. The main namespace host original text, but index to subpages are allowed. E.g., en:s:Illustrations_of_China_and_Its_People.--Upload for Freedom (talk) 02:12, 10 May 2022 (UTC)

What is the subject matter for this gallery? Is it just pictures about China taken by Japanese people? The galleries have no categories so are they just free-standing galleries? -- Ricky81682 (talk) 02:39, 10 May 2022 (UTC)

"亜細亜大観 is a monthly photo book published by Dalian-based Asai Photo Daikansha from 1926 to 1940. A monochrome print is attached to the mount of the photo book, and a short commentary is attached to each photo. It seems that 10 sheets were distributed to members once a month as one set. A Japanese photographer photographed customs, folk affairs, natural scenery, historical buildings, etc. in China, the Korean Peninsula, Mongolia, Tibet, etc., and is a valuable document that conveys the situation at that time."

— [1]

--Upload for Freedom (talk) 03:13, 10 May 2022 (UTC)

Pinging @Jameslwoodward as deleting Admin.   — Jeff G. please ping or talk to me 10:13, 10 May 2022 (UTC)
How about using Category:亜細亜大観 instead of a gallery page to collect the single sub-galleries? They really should be in that Category anyway. Category:亜細亜大観 第01冊 and others should probably also be created, as they are being used but don't exist. That's of course unless there are usable English category names possible, compare Commons:Categories#Category_names. --El Grafo (talk) 11:37, 10 May 2022 (UTC)
On the other hand, the similar 亜東印画輯 for example seems to make a lot of sense to me as an index to the linked subpages. El Grafo (talk) 12:00, 10 May 2022 (UTC)

Policy is very clear -- a gallery is a collection of images or other media files. There is no provision at Com:Galleries for using them for any other purpose. In fact, quite the opposite,

"Galleries without media are not galleries at all. They are considered out of the project scope and meet the criteria for speedy deletion."

An appropriate Category can easily serve the function of an index. .     Jim . . . (Jameslwoodward) (talk to me) 15:36, 10 May 2022 (UTC)

I think the policy should be updated to allow this usage. Categories cannot convey enough information about the gallery subpages.--Upload for Freedom (talk) 23:38, 10 May 2022 (UTC)
@Upload for Freedom: Categories can convey enough information about the gallery subpages.   — Jeff G. please ping or talk to me 23:57, 10 May 2022 (UTC)
How about the date and number of issues? They cannot be seen from category. --Upload for Freedom (talk) 23:59, 10 May 2022 (UTC)
I think it's safe to say that this can do things that a Category can't. I think it's also safe to say that this is an improvement that turns it into an actual gallery. Just do them all like this -> problem solved. El Grafo (talk) 07:05, 11 May 2022 (UTC)
  Oppose per Jameslwoodward above.   — Jeff G. please ping or talk to me 23:57, 10 May 2022 (UTC)

Enable $wgCopyUploadAllowOnWikiDomainConfig on commonsEdit

In order to add a domain into upload_by_url whitelist, someone need to fill a task on Phabricator and submit a patch, which is considered really complicated for new user and even experienced user. But now, we have a new configuration variable called $wgCopyUploadAllowOnWikiDomainConfig, which was introduced recently - if enabled, we could simply add domain into MediaWiki:Copyupload-allowed-domains, and there's no need waiting for deployment of a patch. Sounds pretty great, isn't it? So, I am here to request enabling such function on commons. Please share your opinion, thanks. Stang 07:25, 13 May 2022 (UTC)

I think this would definitely be useful but then we should implement a procedure for urls to be added like the bot requests. --GPSLeo (talk) 07:39, 13 May 2022 (UTC)
Could be similar to the procedure on MediaWiki_talk:Spam-blacklist and MediaWiki_talk:Spam-whitelist, just use {{Ep}} to notify admins. Stang 15:43, 13 May 2022 (UTC)
If I'm reading this correctly, would this make importing free and public domain files from websites easier? And would this also work with the MediaWiki Upload Wizard as it currently does for Flickr (for some people)? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:36, 13 May 2022 (UTC)
No the UploadWizard currently does not support uploading by URL. As there is the function for Flickr I think it would be possible to add this quite easy. --GPSLeo (talk) 16:00, 13 May 2022 (UTC)
  Support.   — Jeff G. please ping or talk to me 10:43, 13 May 2022 (UTC)
  Support. Agathoclea (talk) 12:52, 13 May 2022 (UTC)
  Support. Obviously anything that makes things easier for the people that improve the technical quality of this website should be supported. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:54, 13 May 2022 (UTC)
  Support: This is something that should be in the hands of the local community. I don't think it needs any policy to be in place. Copy uploads are essentially a convenience, so I'd be quite happy with the default policy of leaving it to admin discretion, just like it's currently at sysadmin discretion. When this is done, the existing list of allowed domains should be moved to MediaWiki:Copyupload-allowed-domains so that they can be maintained here as well. --bjh21 (talk) 09:45, 14 May 2022 (UTC)
  Support obviously. --Marsupium (talk) 17:24, 14 May 2022 (UTC)
  Support --Guerillero Parlez Moi 21:45, 14 May 2022 (UTC)
Created an example list based on contents inside InitialiseSettings.php. I replaced *.*.example.com with .*\.example.com, // with #. Stang 22:53, 14 May 2022 (UTC)
@Stang: Are you sure that's correct? The patch referenced from phab:T300407, [2] doesn't seem to make any changes to the parsing rules for the entries, so I'd expect them to be the same as in the current setting, where . matches literally, and * matches precisely one component. --bjh21 (talk) 23:29, 14 May 2022 (UTC)
@Bjh21: I just followed the syntax in Spam-(black|white)list, but yeah, I would ask in the Phabricator task to verify if it is correct. Stang 23:33, 14 May 2022 (UTC)
I tested on my instance and you're correct - I have fixed the syntax of "MediaWiki:Copyupload-allowed-domains". Stang 00:10, 15 May 2022 (UTC)
  Support obviously. Yahya (talk) 21:53, 15 May 2022 (UTC)
  Support. Hulged (talk) 04:02, 16 May 2022 (UTC)
  Support --El Grafo (talk) 09:12, 17 May 2022 (UTC)