Commons:Village pump/Proposals/Archive/2024/01

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

Delete or deprecate or modify Drfop template

Several users like Ooligan expressed concerns or reservations on FoP-related deletion requests that contain wording inspired from {{Drfop}} (for Ooligan's concern, at Commons:Deletion requests/Files in Category:Transfiguration Cathedral, Donetsk). The wordings made by nominators are not comprehensive and not detailed enough to show what is the problem of a certain public monument accused to be unfree for commercial CC/PD licensing here. The template itself appears to be live, and can be used in the nominations even if it only provides country name as the sole parameter.

I am proposing now to either take down this template or at least deprecate/modify it, so that nominators are now forced to explain the FoP-related problems with greater detail. While this may be in use in thousands of DRs from 2010s, I suggest simply copy-pasting the content of the template to those DRs transcluding it to avoid abrupt content loss in those DRs, and take down the template afterwards, if the consensus leans towards nuking this template entirely. Ping two users who debated at the template's talk page: @Bluerasberry and Jameslwoodward: . JWilz12345 (Talk|Contrib's.) 23:49, 1 January 2024 (UTC)

Given that this template has been so heavily used, any substantive changes to it should certainly first involve subst'ing existing uses of the template (or converting them to use an archived version). It is important to preserve what was actually said in a deletion debate, not to have it changed by a later template change.
Yes, this template could be greatly improved, and I'd have no problem with making this version archival and coming up with something that gave a better explanation of the issues at hand. That said, though: the norm is, indeed, that derivative works violate copyrights. FoP is a widespread exception, not a norm. Even in countries that have "strong FoP" it can have weird limitations (e.g. the Germans not allowing aerial photos under their FoP). - Jmabel ! talk 00:42, 2 January 2024 (UTC)
Comment I previously stated that I felt the template gives unclear information. I continue to feel that it should lead with a statement of concern. I am ready to comment on any modification proposal. There are 1000+ transclusions, so someone is using this. Bluerasberry (talk) 00:58, 2 January 2024 (UTC)
@Jmabel and Bluerasberry: I modified now my message accordingly. JWilz12345 (Talk|Contrib's.) 02:05, 2 January 2024 (UTC)

Note, by the way, that I wrote the template in the first place.

I don't think the subject DR is a good case to cause discussion of changing the template. The DR discusses a building that was destroyed and then rebuilt. It concludes incorrectly, that the replacement does not have a copyright except for the parts that are different from the original. Of course we know that if a modern artist copies a Rembrandt, the resulting work has a new copyright. This is emphasized by the fact that before Bridgeman, even photographs of a Rembrandt had a copyright.

Note also, that the DR is not an FoP issue -- there is no FoP in Ukraine, so perhaps we need a template summarizing the status of a DW to use at the beginning of DRs of DWs.

Of the 125 countries that we see most often on Commons, 65 have no FoP (see User:Jameslwoodward/Sandbox2. I don't understand what Bluerasberry's "statement of concern" might be -- perhaps they would be good enough to write it out here? .     Jim . . . (Jameslwoodward) (talk to me) 14:27, 2 January 2024 (UTC)

I followed up on the template talk page. Bluerasberry (talk) 19:41, 2 January 2024 (UTC)

"Slideshows" category on main page

In the "Content" box, By Type section, I think that we should have a category for slideshows. I think this would reinforce the culture of CC presentations and motivate in properly categorising presentations. Right now, Category:Presentations is very disorganised and includes photos and videos from presentations. I think that being able to access the slideshow files would be beneficial. Egezort (talk) 21:26, 4 January 2024 (UTC)

I agree! Sometimes is difficult to find even slideshows about Wikimedia events! Theklan (talk) 21:39, 4 January 2024 (UTC)
There is at least the Category:Wikimedia_presentation_slides , which is exclusively for slides, but yes! And not everyone uploads their slides with this category because it's not so visible. Egezort (talk) 22:56, 4 January 2024 (UTC)

Put "Uploads" into mobile menu

  1. Visit https://commons.m.wikimedia.org/ with your cellphone, and login.
  2. On the Commons home page, you will notice a big blue button in the middle of the screen: "Upload".
  3. Now tap the person icon in the upper right.
  4. You will see in the menu "contributions" but no "Upload".

In step 2 we have learned that Upload is a very important function. But for no good reason one cannot check ones uploads from the mobile menu. One needs the desktop menu, or entering the Uploads URL directly. Jidanni (talk) 04:00, 6 January 2024 (UTC)

I may be confused, but isn't #2 about uploading a file and #4 about seeing the Special:MyUploads page? Are you saying it should be possible to start an upload from any page, or that it should be possible to easily see Special:MyUploads? - Jmabel ! talk 07:45, 6 January 2024 (UTC)

Start File Navigation from Current Page in Large Categories

Large categories, such as Category:Scans from the Internet Archive, pose an issue when users click the category link from a file page like File:The Gull (IA v17n1gullv17ngold).pdf. Currently, it always starts from the first file in the category. However, users are more likely to want to see files around the current file. Therefore, can we modify the link to direct users to Category:Scans_from_the_Internet_Archive&filefrom=v17n1gullv17ngold? This adjustment would provide more relevant file links for the user.

To implement this, I propose the introduction of a MediaWiki magic word like __STARTFROMCURRENTPAGE__. When added to category pages, this magic word would ensure that when users click the category link from a file or other types of pages, it will start from the page's sort key.

It's important to note that Wikimedia Commons differs from Wikipedia, as pages are not interlinked. Consequently, many pages are not indexed by Google due to a lack of links from other pages. Implementing this change and allowing /w/index.php?title=Category in robots.txt would create more interlinks, potentially leading to increased file indexing.

維基小霸王 (talk) 02:50, 2 January 2024 (UTC)

Since this feature would require changes to MediaWiki, you should probably ask at m:Phabricator, not here.
For what it's worth, this change would likely make search indexing worse, not better - each file would link to a slightly different page within the category, creating a larger number of redundant pages to be indexed. Omphalographer (talk) 19:31, 2 January 2024 (UTC)
It is pretty easy to add sane navigation to the category page, if the images named (or sorted by sortkey) after a pattern that imposes order. - Jmabel ! talk 23:57, 2 January 2024 (UTC)
This is possible for middle-sized categories, but not for very big categories like what I have mentioned. [1] 維基小霸王 (talk) 01:18, 3 January 2024 (UTC)
I can see why that would be tough at that scale. So basically, what you'd want is to be able to set things up so that if the file's sortkey (by default the filename) is FOO and it is in Category:BAR, you'd like an easy way to get to https://commons.wikimedia.org/w/index.php?title=Category:BAR&filefrom=FOO. I'm not 100% sure that is desirable as default behavior, but I can see why it would be nice to have a choice of that mode. I think it should be possible to achieve that client-side with a user script. - Jmabel ! talk 02:31, 3 January 2024 (UTC)
Part of the problem here seems to be that these files have DEFAULTSORT set to unhelpful values (the Internet Archive file ID). Removing those might improve matters. Omphalographer (talk) 02:32, 3 January 2024 (UTC)
Yes, if you are not sorting the category in the order you want it, you'll have quite a problem getting what you want. On the other hand, I think that particular DEFAULTSORT is going to keep the pages of a book together pretty much as you'd like them to be.
In the example I gave above, the HTML for the category link would currently be <a href="/wiki/Category:BAR" title="FOO">BAR</a>, which is pretty tractable to massage in script if what you want is to produce <a href="/w/index.php?title=Category:BAR&filefrom=FOO" title="FOO">BAR</a>. Jmabel ! talk 03:20, 3 January 2024 (UTC)
@Omphalographer: I guess Phabricator would require a local consensus first?
Presently, only the first page of every category was allowed to index. Maybe more should be allowed to index on Wikimedia Commons for more links to files. Any better ideas? 維基小霸王 (talk) 01:19, 3 January 2024 (UTC)
I like this idea. -- Tuválkin ✉ ✇ 05:08, 6 January 2024 (UTC)
So I think no one will object if I propose a magic word on Phabricator to make optional start from the page's sort key? --維基小霸王 (talk) 02:32, 7 January 2024 (UTC)
I think you'd do better to indicate simply that you want a way to go into a category and start from the page's sort key, rather than dictate to the developers how you want it done. As I said above, I think it would be pretty simple to do this client-side with a user script, so it may just be a "gadget". - Jmabel ! talk 03:34, 7 January 2024 (UTC)
Tracked in Phabricator
Task T354500
Thank you. I will make a proposal. 維基小霸王 (talk) 01:07, 8 January 2024 (UTC)

refering to realistic in AI categories

see Category:Realistic animals by DALL-E that by refering to these files as being realistic is a falsehood which damages Commons and the wider movements reputation of realiability, accuracy, and trustworthy source. The files should not be udentified as such. Suggest that the should clear distinguish themselves as machines(AI if yuo wish) from both photographers and illustrators. Propose that all DALL-E categories are styalised as Machine Generated(AI) illustrations by DALL-E in the specific example it would become Category:Machine Generated(AI) animal illustrations by DALL-E the veiwer can decide on whether they consider it by the peacock term "realistic"Gnangarra 13:27, 9 January 2024 (UTC)

This category is exactly so that you can move images that have inaccuracies / are unrealistic out of the category. You misunderstood the point of it. Moreover, you're confusing WMC with Wikipedia and ignore file descriptions and file titles. Also see Category:Inaccurate paleoart. The proposal regarding category renaming could be reasonable but I'd suggest that it's discussed via cat-for-discussion procedures and in a way where the title matches the contents. I've always argued (mainly in this context) that titles, categories, and file descriptions should match the actual file contents so renaming such categories may be something I'd support. Prototyperspective (talk) 13:36, 9 January 2024 (UTC)
this not just renaming a single or associated group of categories, specifically this is about setting a policy for such styles including the removal of peacock/suggestive terminology that can mislead those searching media files. DALL-E is just the example. Gnangarra 13:44, 9 January 2024 (UTC)
I'm also concerned about misleading search results but less so when it comes to clearly labelled AI art than lets say unexpected animations of people dying and porn images. I can't really understand why people are so worried about clearly labelled AI images showing up in search results in a relative sense. Still, I support making things clearer. Particularly one thing I suggested was having a tag note in the corner of an image or appended to file titles that e.g. says "[Made using AI]"; something similar could be done for categories but seems to already be the case in your examples (I addressed further things above). Prototyperspective (talk) 14:21, 9 January 2024 (UTC)

Strongly oppose "realistic" in the names of categories that users can freely add. It involves a judgement call. If we were to allow this, it should involve at least the level of rigor we bring to judging Quality Images. - Jmabel ! talk 19:41, 9 January 2024 (UTC)

There is Category:Inaccurate paleoart; for images made involving AI tools I thought it would be best if inaccuracy is assumed and the default.
Thought the cat would be useful and don't really care about it even though I don't understand why people such strong feelings and concerns about AI images particular but not other respectively comparable issues. Just nominate the cat for deletion. I thought having a way to separate lets say File:Parrot in Peaky Blinders style.png and File:Capybara espacial.jpg, from images aiming or achieving to be realistic depictions like File:Polygon illustration of a dog.png, File:Monkey in watercolour.png and File:Ai Generated Images Tiger.png would be useful (and possibly needed so that one assume inaccuracy if the cat is missing and easily find images that are more realistic or unrealistic). Again I'd suggest just making a CatForDeletion/Discussion post and I don't care what happens to the cat if people don't see usefulness in this distinction. Prototyperspective (talk) 21:59, 9 January 2024 (UTC)

Let's say we are looking at number 06 in an automatically numbered series. Well there should be links to 05 and 07 on it, so we don't need to go back to an index page to see the next one.

No, I'm not saying the uploader person should remember to make the links.

I'm saying the upload creation process, where the 01 02 03 are assigned, should make the links.

And in fact they need to be made for all already existing series too...

And perhaps have all the links, 01 02 03... on all the pages, so one can jump around, not just to the next and previous.

Yes, I know one can manually edit the url in one's browser's omnibar. But that is so old fashioned.

Jidanni (talk) 13:24, 11 January 2024 (UTC)

Perhaps something like this should be available as an option, but it should absolutely not be assumed automatically from file naming. I routinely use a number on the end to distinguish photos I took of the same subject, but it is very rare when they are intended as this sort of sequence. - Jmabel ! talk 16:32, 11 January 2024 (UTC)
In principle, a good idea, but should not be automatic, because (like Jmabel said above) often numbers are merely used to differentiate photos, not to imply a sequence. I support this idea for a new optional tool... --P 1 9 9  ✉ 16:44, 11 January 2024 (UTC)
When it's autonumbered, for example when uploader gives just one name for the batch, then yes the sequence links can be inserted by default as part of the upload wizard's autonumbering process. When the uploader provides separate numbers, then there's no autonumbering thus should be no automatic sequence links. Jim.henderson (talk) 06:36, 14 January 2024 (UTC)

Ideas wanted to tackle Freedom of Panorama issue

Hello all! We are looking for ideas to tackle the problem of media deleted because of Freedom of Panorama-related issues, and we're looking especially for admins and people who are knowledgeable in this issue to intervene. If you are interested, please join the discussion. Thanks in advance! Sannita (WMF) (talk) 17:03, 29 January 2024 (UTC)

Retiring License template tag

In 2011 I created {{License template tag}} template, an empty template which is added to 5 license layout templates and transcluded in almost all Commons files. This tag template was essential in creation of SQL queries for files missing a link to this tag which usually means that they are missing any license. Some years latter Extension:CommonsMetadata was created that adds Category:Files with no machine-readable license to files without license. I am no longer using {{License template tag}} template and I do not think it is needed anymore. At the same time there is an issue with Commons database growing way too fast (see phabricator:T343131) and this template contributes to this issue. I would like to propose to stop using this template, however I am not sure if others do not use it for something. Jarekt (talk) 17:56, 21 January 2024 (UTC)

 Oppose. User:AntiCompositeBot's NoLicense task uses {{License template tag}} to check for license templates, because the CommonsMetadata category was not reliable enough to detect all license templates. It's also not possible to replace it with a search query because of the number and complexity of primary and secondary license templates. AntiCompositeNumber (talk) 19:24, 21 January 2024 (UTC)
https://commons.wikimedia.org/w/index.php?search=hastemplate%3A%22License_template_tag%22%20incategory%3AFiles_with_no_machine%2Dreadable_license&title=Special%3ASearch&ns0=1&ns6=1&ns12=1&ns14=1&ns100=1&ns106=1 says there's at least 800 files with the template in the category. AntiCompositeNumber (talk) 19:39, 21 January 2024 (UTC)
AntiCompositeNumber I am glad I asked. If this template is used than we should keep it. --Jarekt (talk) 20:04, 21 January 2024 (UTC)

Per AntiCompositeNumber reply I would like to withdraw my proposal. --Jarekt (talk) 20:06, 21 January 2024 (UTC)

Unresolve. Most of such results are error that should be fixed and I have reduced the number of results from 800 to 120.--GZWDer (talk) 23:04, 21 January 2024 (UTC)
Other than one file I tagged no permission, only one file left in search result: File:GFDL (English).ogg.--GZWDer (talk) 14:36, 4 February 2024 (UTC)
@AntiCompositeNumber and GZWDer: I just checked Category:Files with no machine-readable license and I do not see any files with {{License template tag}} template (https://petscan.wmflabs.org/?psid=26927412). I guess that if there are files in Category:Files with no machine-readable license that have undetected license than those license templates need to be fixed, as described in here. I still think that it might be time to retire {{License template tag}} template in favor of detection by MediaWiki software. --Jarekt (talk) 14:50, 7 February 2024 (UTC)
@Jarekt AntiCompositeBot and iNaturalistReviewer no longer check for {{License template tag}}. I've had ACB log every instance of a file that had the category and the tag for the past few days, and none have had a license template on the review revision. Some had a license template on a previous revision, while others never had one. I'm satisfied that the category is reliable enough and have no objections to removing {{License template tag}}. It would probably be a good idea to slowly phase it out, starting with a license that is popular enough for someone checking for the tag to notice. AntiCompositeNumber (talk) 00:26, 5 March 2024 (UTC)
AntiCompositeNumber, Thanks for following up on this. I will start retiring {{License template tag}}. As for slow/fast phasing out, once some licenses do not have it than queries that search for files with missing tag will be finding those making them useless. So I do not see how slow phaseout will be useful. Am I missing something? --Jarekt (talk) 01:50, 5 March 2024 (UTC)

✓ Done --Jarekt (talk) 05:04, 10 March 2024 (UTC)

Jarekt, I had to revert your removal of {{License template tag}}. It appears that Commons:UploadWizard tests for the presence of {{License template tag}} (see mw.UploadWizardLicenseInput.js and CommonSettings.php). —RP88 (talk) 17:44, 10 March 2024 (UTC)
It also appears Zhuyifei1999's YiFeiBot relies upon {{License template tag}}. If you look at its edit history it became very busy adding Category:Media without a license: needs history check after the template was removed from the base templates. Now that it has been added back, YiFeiBot is now busy removing the missing license categories it added. —RP88 (talk) 19:03, 10 March 2024 (UTC)
RP88, thank you for handling this. I guess {{License template tag}} is part of many systems now. I will document it on it's page so in case years from now someone else tries to retire it, they will know what to check. --Jarekt (talk) 22:56, 10 March 2024 (UTC)
Do we even need that bot task? I've always found it just made reverting vandalism more annoying. AntiCompositeNumber (talk) 21:07, 11 March 2024 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2024/01&oldid=867346891"