Commons:Village pump/Proposals/Archive/2022/04
 | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Multilingual welcome?
User:Wikimedia Commons Welcome this page currently can only show an english one-liner. can we mark this page for translation or make it multilingual in some way? RZuo (talk) 08:26, 14 April 2022 (UTC)
Done I prepared this page for translation. --GPSLeo (talk) 10:05, 14 April 2022 (UTC)
Formalize .STL files as another exception to rules on categorisation by filetype
Hello. We have a few exceptions for the "no topical categorization by file type" rule, most notably SVG files. This exception is here because .SVG files in Commons are here to serve a fundamentally different purpose than any other filetype we support, while there's no such difference between say PNG and JPEG, that is, both fill the same role. I'd like .STL files to be formalized as another filetype that's in the same situation as .SVG, as they are de facto already being categorized in that manner. The first reason is because they are the only 3D filetype we currently support. The second reason is that, even if we eventually add support for more 3D filetypes, a certain difference of purpose could be argued between STL and our likely adoptions: STL is a CAD format much used in 3D printing, while both glTF (arguably the best possible format for Common's scope and Wikimedia's mission) and .blend (a filetype already requested in some discussions and Phabricator tasks) would both service a more general 3D showcasing role, and are not neutral file formats. I feel like we should adapt our categorizing rules for the environment we are currently in, and if in the future some other CAD format is added (a task which would most likely happen after support for something like glTF, which might be an argument for considering this event as very distant thing), then that can be adapted to with the simple creation of a parent category.
I also take this opportunity to link {{Catsbyfiletype}}, present in the category mentioned before, which gives background information and links to relevant discussions. Also, if users agree with my points, the template's text would need to be amended. YuriNikolai (talk) 03:59, 1 April 2022 (UTC)
Global deleted image review 2
Links to Previous VP/P discussion and previous RfC. In late 2014, there was a discussion about enabling a global group which allows member to view deleted files and corresponding description page. I don't really know why this proposal got no follow-up in the past, but I would like to bring it out again. If you would like to make any comment about this proposal (create a "Global deleted image review" usergroup), feel free to leave your comment at the new RfC page. Thanks! Stang★ 14:27, 2 April 2022 (UTC)
Image rendering
On my Windows laptop, the quality of the image that I see at e.g. https://commons.wikimedia.org/wiki/File:Steephill_Cove,_Isle_of_Wight,_England.jpg is noticeably better, e.g. in terms of sharpness, than the quality at e.g. https://upload.wikimedia.org/wikipedia/commons/0/07/Steephill_Cove%2C_Isle_of_Wight%2C_England.jpg, which is what I see when I click on the image on the former page. For me, this is true of images generally. If that is the case for other users too, and not just a quirk of my device, then may I suggest that whatever rendering software is used for the former page is also used for the latter, and indeed universally. ITookSomePhotos (talk) 22:19, 4 April 2022 (UTC)
- The quality of the preview image (and all other JPGs scaled down by the Wiki software) is no better than the full-size image. The preview has merely been sharpened by software in order to be better recognizable in the reduced representation, even in thumb size. If this were not done, most thumbs would look blurred and out of focus.
- If you now go and compare a preview image scaled by the wiki directly with an original scaled to the same size in your browser, then this artificial sharpening is missing in the second case, because your browser does not do any sharpening. (It may be that there are browser plug-ins for this, which I don't know about).
- From the resolutions offered on the image description pages, just choose the one that suits your purpose, they are all resharpened except for the original. If you want to use the original, use that. Of course, in this case you have to do the image enhancements yourself. For my part, I would immediately request the deletion of all my photos if any Mediawiki automatism were to tamper with my original uploads. --Smial (talk) 18:45, 5 April 2022 (UTC) Translated with www.DeepL.com/Translator (free version)
- I see. People knowingly choosing resolutions with or without sharpening enhancements and/or doing their own enhancements of downloaded images is one thing; people viewing images on a screen without particularly being aware of or caring about any of this, but just wanting to see "best quality" on the screen, is another. However, if the full resolution is displayed, and scaling is left to the browser, then I understand that the wiki software has no control over how that happens. ITookSomePhotos (talk) 19:51, 5 April 2022 (UTC)
- @ITookSomePhotos and Smial: The sharpening is only for jpg; any png image will look fuzzy when scaled down (due to design decisions discussed in phab:T192744). — Jeff G. ツ please ping or talk to me 09:53, 6 April 2022 (UTC)
- I see. People knowingly choosing resolutions with or without sharpening enhancements and/or doing their own enhancements of downloaded images is one thing; people viewing images on a screen without particularly being aware of or caring about any of this, but just wanting to see "best quality" on the screen, is another. However, if the full resolution is displayed, and scaling is left to the browser, then I understand that the wiki software has no control over how that happens. ITookSomePhotos (talk) 19:51, 5 April 2022 (UTC)
Duplicate file names added to COM:FNC#2
To have COM:FNC#2 include files with duplicate names, where the names are different only in a capital letter. Example: File:(1)Flying fox 049.jpg & File:(1)Flying Fox 049.jpg. I would say this would meet FNC#2 since the name is ambiguous as the only differentiating factor of the files is a capital letter. However I have had both files moved and requests declinded for this and it should be explicitly stated if these should be included as FNC#2 or not. Terasail[✉️] 18:18, 6 April 2022 (UTC)
Flying_fox_049.jpg){kind=link}
Flying_Fox_049.jpg){kind=link}
- Usually the "ambiguous" refers to the subject of the image, not file names being too close. For the issue of filenames resembling each other, your example is not the worst one, there are the issues of "1" (one) vs "l" (L) and similar, and surprising ones when different writing systems are involved (such as СССР vs CCCP – try to search for those strings on this page if not otherwise evident).
- For your own files, you can ask for renaming according to criteria one (request by uploader), otherwise I'd be reluctant, unless some of the filenames are unnecessarily non-descriptive. There are cases where the case is chosen by purpose and not only for distinguishing. For your example, I would append some item of information, e.g. "Kensington Park" and "Randwick" or "2017" and "2019".
- I agree with LPfi that this doesn't fall within the existing criterion 2. I think an addition along these lines would be good, but I think it should be a new criterion (7?) rather than yet another case of criterion 2. It should be specified that the newer file (strictly, the one created or renamed most recently) should be renamed, to avoid abuse by uploading a file with a name very similar to an existing one to force renaming of that existing file.
- As I recall, Special:Upload has sometimes warned me that the name of the file I was uploading was too similar to that of an existing file. It would be good if the threshold for "too similar" matched between Special:Upload and the new renaming criterion. --bjh21 (talk) 19:56, 6 April 2022 (UTC)
- It might be difficult to warn about all similar filenames. The Cyrillic case I gave as example is easy, as it is well-known and the number of characters is small, but in what cases character sequences in non-European writing systems might look similar in some rendering is probably not well-known, and not easy to discern automatically from their Unicode description. The upload procedures should warn about the cases they know about (does the Upload Wizard use Special:Upload?), but I assume there will be cases left for manual intervention. I'd support the "leave the oldest alone" principle. –LPfi (talk) 20:06, 6 April 2022 (UTC)
- @LPfi: Yes, you're right: there will be cases where renaming is justified even though no reasonable automated system could detect it. --bjh21 (talk) 21:43, 6 April 2022 (UTC)
- It might be difficult to warn about all similar filenames. The Cyrillic case I gave as example is easy, as it is well-known and the number of characters is small, but in what cases character sequences in non-European writing systems might look similar in some rendering is probably not well-known, and not easy to discern automatically from their Unicode description. The upload procedures should warn about the cases they know about (does the Upload Wizard use Special:Upload?), but I assume there will be cases left for manual intervention. I'd support the "leave the oldest alone" principle. –LPfi (talk) 20:06, 6 April 2022 (UTC)
Modifying Template:Cultural Heritage Armenia
i propose editing Template:Cultural Heritage Armenia/en by changing "ID" with "[[d:Property:P3170|ID]]".
i was trying to find out what the monument ID 8.26/1.2 refers to, but there is no explanation to what id this is or where is a database. it took me quite some time to find Cultural Heritage Armenia ID (P3170) (but i still dont know what ID 8.26/1.2 is). i hope this link could point users to the most useful info we have. the template has 140k transclusions, so here's a proposal to gather consensus.--RZuo (talk) 09:58, 15 April 2022 (UTC)
Add glTF file support/preview
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)
Proposed move of everything in Category:Borodianka Raion to Category:Bucha Raion
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)
- 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)
Use VRTS for OS
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, then 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)
Suggestions at File license template
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)
- 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)
- 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)
- Regardless of what we suggest in this specific template, I see absolutely no reason to stray from the default (e.g. in UploadWizard), which is CC-BY-SA-4.0 only. So that's a valid argument for changing the default itself, but it just doesn't make sense to suggest something different in one specific template, which ends up confusing things. -- King of ♥ ♦ ♣ ♠ 08:13, 2 June 2022 (UTC)
Discussion result
In the {{File license}} template the link to {{PD-self}} should be replaced with {{self|cc-zero}}. --GPSLeo (talk) 14:20, 23 May 2022 (UTC)
Votes
Support --GPSLeo (talk) 14:20, 23 May 2022 (UTC)- Support Nosferattus (talk) 15:56, 26 May 2022 (UTC)
- Support -- King of ♥ ♦ ♣ ♠ 08:13, 2 June 2022 (UTC)