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.
Mass requests to GLAM to mirror PD content on Commons as well as on Internet Archive
The draft message below was one I was one I was considering that appropriate Wikimedia contributors forwarded to GLAM contacts they know, that have contributed public domain material to Internet Archive. The proposal was that this was sent by GLAM contact as a mass request to as many of them as possible ( assuming that they can be identified.)
Whilst it is unlikely, a 'take-down' of the Internet Archive, however temporary would be potentially disruptive, to readers and user alike, that make use of the vast collections of public domain material that the Internet Archive provides access to. It would be useful to have a 'backup' in place.
It is therefore politely but strongly suggest, that in respect of material you have been or are able to confirm as being in the public domain (taking into due consideration copyright terms of other jurisdictions such as Canada and the United Kingdom), you actively consider uploading such public domain material "in parallel" (as well as to the Internet Archive) to other archives and sites that are working to make the public domain accessible to others. One such site being Wikimedia Commons (commons.wikimedia.org). Wikimedia Commons is recomended, because public domain material uploaded to it, can be made use of very quickly on many other Wikimedia sites like Wikipedia (en.wikipedia.org) and Wikisource (en.wikisource.org).
If you were also able to consider other potential projects in relation to Wikimedia sites (see https://outreach.wikimedia.org/wiki/GLAM), if you have not already done so it would be very highly desirable.
It would also be appreciated if you could share this message with colleagues in both your own institution and further afield so that they can also make a decision about uploading content "in parallel".
Let's keep the public domain and knowledge, free and accessible, with a fully supported context for future generations!
I know that Commons has some projects to pull material from other sites, but I did a quick search and couldn’t find one for the Internet Archive. There should be one. Brianjd (talk) 07:33, 14 June 2020 (UTC)
Unfortunately the ability to import from other websites is largely limited to a handful of websites, mostly Panoramio (now defunct) and Flickr. It would actually be handy to have a tool that could theoretically import from any website and automatically checks websites for their copyright licenses and that certain websites could be "Whitelisted" (as a whitelist would be far more manageable than a a blacklist) and then put all the files up for (human) review. Wikimedia Commons should have been presenting itself as an alternative to the Internet Archive and Flickr Commons among many others years ago. Perhaps this crisis will bring more attention to Wikimedia Commons. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:26, 20 June 2020 (UTC)
Mass "Evacuation" copy of Public domain resources from Internet Archive to Commons.
This is almost certainly going to be controversial but:
It is proposed in light of the litigation threats IA is facing, that there is an automated effort, to "evacuate" copies of as many public domain 'books' from Internet Archive to Commons,as possible. User:Fæ already has some scripts that are doing this for a small number of collections already identified.
Initially, subject to appropriate metadata checks being feasible, what would be needed is a bot or script that essentially goes through a list of every single "book" scan on Internet Archive, and if its a work from between 1780 and 1870 (because that's the latest date something can be reasonably considered for {{PD-old-assumed}}), in English, (ideally a work published in the US), and under a commons compatible license, the bot grabs it and 'reliably' "mirrors" a suitable hi-res PDF to Wikimedia Commons, with the full IA style metadata, being placed in a suitable {{Book}} template on the file description page. If a suitable file already exists on Commons, (SHA1's could be checked) then that file is skipped. (Although a metadata only import could be considered, as well.)
Is it feasible, to do this for over 100,000 items? I don't think Commons Batch Uploading has ever attempted anything that big...
FYI Portable Antiquities Scheme 559,631 photographs, Geography uploads were larger. 100,000 files can take me about a week or two, but if there are custom fixes and interventions, you can count on it being several weeks, especially as this is summer and everyone wants time in the sun. --Fæ (talk) 17:16, 20 June 2020 (UTC)
Thanks. However I prposed this here rather than directly on the talk page for your effort, because I felt it needed a clear consensus from the whole community.ShakespeareFan00 (talk) 17:54, 20 June 2020 (UTC)
Perhaps some background could be helpful. According to this NYT article from 1 June 2020, Penguin Random House, HarperCollins, Hachette and Wiley sue the Internet Archive for making books available for lending which are still protected by copyright. This electronic lending was originally quite restricted (just one copy per book at a time) but these restrictions were lifted recently due to the Corona crisis. The Internet Archive has already stopped this. However, the problem is, that this lawsuit threatens the existence of the Internet Archive. In theory, there could be up to $ 150,000 statutory damages per each of the 1.4 million titles per this analysis and this article at vice.com. --AFBorchert (talk) 18:19, 20 June 2020 (UTC)
Regarding the proposal: Disk space is not an issue at Commons. The precious resource is our time we have to fix things after the initial upload. Hence, it is of greatest importance that we focus on books where we can be sure that they are in the public domain. The description, categorization etc. should be good enough. This means that we would need a slow start with trial uploads to see if there are problems which should be fixed before we upload the whole amount. --AFBorchert (talk) 18:34, 20 June 2020 (UTC)
Support I support importing books to Commons as long as we are sure that most of them are in scope and there are no copyright issues. The suggested approach above gives me no reason to worry. So it's a go from me.
I'm also willing to risk a few copyvios if time is an issue. We can either mark those with risk as "Review" or we can simply delete them all and go through a review and undelete them if they are okay (or when they are okay). --MGA73 (talk) 18:45, 20 June 2020 (UTC)
Some uploads are already being made at Category:Books from the Library of Congress. I'm finding a few post 1870 works in the uploads being made. Nothing that looks problematic on the items reviewed so far, but there is only so much a single contributor can do. One issue I've found already is the use of 1800 as a placeholder date. The expertise of other commons contributors in reviewing things like dates against the scans and other sources ( Commons now has a set of the Catalog of Copyright Entries (Category:Catalogs of Copyright Entries BTW ) would be appreciated. ShakespeareFan00 (talk) 19:29, 20 June 2020 (UTC)
Strong support, I've imported many individual books from the Internet Archive in the past and have always hoped that this community would one day mass-import Internet Archive books, if Wikimedia Commons would want to be taken seriously as "a public domain library" such an import is a must, and more importantly it would also preserve this knowledge online in case it might be lost forever. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:15, 20 June 2020 (UTC)
Strong support Scope be damned, we need to import everything we can from IA while we still can. (We can sort out any scope issues later. Also, it sounds like Commons is the only organisation willing and able to take on a task like this, so even if a file is out of scope, perhaps we should assist in preserving it for those who are interested in it.) One question: why a cutoff of 1870? {{PD-old-assumed}} says it can be used for anything up to 120 years ago, which would currently be 1900. Brianjd (talk) 06:59, 21 June 2020 (UTC)
1870 to take into account potentially longer terms outside the US, 2020-140 (2 lifetimes) + 10 years margin = 1870. I will also note that 1870 is when Copyright functions were centralized in the US, and thus after that date the Library of Congress is more likely to hold 'deposit copies'.
The 1780 lower cutoff was because prior to that it was felt more difficult for volunteer effort to verify certain information, earlier works, typically being in libraries special collections, with varying access requirements to protect works that old.
If there is a view that there's sufficient expertise on commons to robustly upload, evaluate and review items that are dated before 1780 or after 1870 (taking into account the issue of placeholder dates, differing copyright terms outside the US.) then I would agree Commons could potentially rescue EVERY public domain book on IA that's compatible with Commons licensing. ShakespeareFan00 (talk) 07:19, 21 June 2020 (UTC)
My sense of this is that Library of Congress book scans are pretty darn reliable, and anything up to 1899 is going to be 95%+ unchallengeable as PD. The current run today will cover 1801-1835 (8,000 books) and I'm inclined to push to go as far as 1899 as the maximum date.
Unfortunately there's no consistent filter for source publication country on archive.org. Though technically it would be possible to pick out publisher names and location (like "Chicago") in practice this would take up so much volunteer time, it's probably just better to get on with it and if necessary do a little triage on the debatable <5% cases which might result from imports dated 1870-1899. --Fæ (talk) 12:04, 21 June 2020 (UTC)
@Brianjd: Nice sentiment, but I don't think WMF or the Commons community would tolerate holding a 'hidden' archive of material whose status or 'scope' could not be definitively determined. ShakespeareFan00 (talk) 07:38, 21 June 2020 (UTC)
I think the Commons community and the WMF already tolerate a "hidden archive", most of which are copyvios. If they don't, the WMF would have been permanently deleting every file that had been DMCA'd after the Commons community says the office action is okay. So I don't see why a "hidden archive" of IA files whose copyright status or scopeness could not be determined would be any different now. pandakekok909:36, 21 June 2020 (UTC)
@ShakespeareFan00 and Pandakekok9: I agree that we can have (and already have) a "hidden archive". As I said above we can copy files to Commons and delete them and undelete if/when the copyright expired. So if we have a reason to think most of them are in scope it is just a matter of doing a mass import. We should only "speedy delete" those we think are problematic. --MGA73 (talk) 09:45, 21 June 2020 (UTC)
In addition, having a "hidden archive" could very useful for files whose copyright is expected to expire at a certain year. For example, a painting was deleted in 2014 because it's still not free in Mexico, whose copyright lasts life of the author + 100 years. And the painting's copyright will expire in 2021. Once we are on that year now, we could just check every file at Category:Undelete in 2021 and quickly bring it back to life (including the history of the file's description), with no need to reupload it again. Imagine if we can't undelete an old movie whose filesize is 5 GB. To reupload such size again would be a huge pain! (At least for me and everyone who is in a 2 Mbps connection) pandakekok909:56, 21 June 2020 (UTC)
This proposal should SOLELY be about 'books' which are clearly 'public domain', and that was why an upper cutoff in terms of dates was applied.
Copyvios on Commons (or other WMF projects), should NOT be tolerated. The whole reason IA is in trouble is because publishers ARE exercising copyrights they understand they are entitled to. Thusly WMF projects and Commons should absolutely avoid making themselves a potential next target, by refusing to upload works still in copyright from the outset.(And no this isn't a "Chilling Effect" but basic common sense.) Has anyone contacted WMF-legal yet for an official position?
For the above reasons, I cannot and never could support a "hidden archive" of copyvios, however well intentioned some people might think it would be.
WMF (and by extension individual projects) in my view SHOULD be perma-wiping files subject to legitimate DMCA takedowns, to send a very clear message that it doesn't support copyright infringement either. (I would hope there are measures in Special:UploadWizard and related pages to prevent accidental re-upload of previously "office" ed files.)
My apologies if I sound slightly strong-viewed on this, but I hold strong views.
Another consideration, that may need to be considered, is if someone from GLAM, needs to actually let IA know they might suddenly have a lot more traffic of a focused nature. ShakespeareFan00 (talk) 07:47, 21 June 2020 (UTC)
Those IA files should obviously be imported here, because that's a commons thing to do, seeing Special:NewFiles without the patroller's filter. So I won't bother with using a support template. I agree with Brianjd that we should import everything from 1780 to 1870 ASAP and ignore COM:SCOPE for now. --pandakekok909:46, 21 June 2020 (UTC)
IA should be contacted directly to expedite the process, and an import of such a size should be under a dedicated bot account only.--BevinKacon (talk) 17:33, 21 June 2020 (UTC)
The Internet Archive contains about 1.5M texts published before 1870, hundreds of thousands of public domain or freely licensed images and thousands of public domain movies. They're a very small part of the data the Internet Archive holds, so even if we downloaded it all in one day it would barely register on their graphs. We're not able to host the uncompressed master files, so any mirroring at Wikimedia Commons must not be considered a preservation effort. Mirroring can however help increase access (for instance for users whose download speed from the Internet Archive is too low). For the books, we'd have to decide whether to import DjVu or PDF files when both are available. The download and upload must be performed from a server in the USA, preferably on the West Coast, because transoceanic download from the Internet Archive tends to be slow. Nemo17:42, 22 June 2020 (UTC)
@Nemo bis and Fæ: I believe Fæ is referring to the feature where files are imported directly to the Commons server, without going through the user’s own computer or Internet connection. Commons servers are based in the US, which is why we have to obey US laws as well as relevant local laws. I vaguely remember something about them being in Florida, but beyond that I don’t have any relevant information. Brianjd (talk) 05:05, 23 June 2020 (UTC)
How certain is the public domain status of the non book 'media'? (Commons has to be sure that media isn't just out of copyright in the US, but globally.)
How reliable is IA metadata, The first batch of some recent efforts encountered the use of 1800 as a placeholder date?
I can probably see why Commons can't host Massive ZIP files of Jpeg or TIFF scans. Are there pre 1870 texts on IA that are only in DJVU format?
Is there a way for the IA side of things, to directly upload to Commons? Rather than relying on user and bot scripts on the Commons side?
(Aside) Is there 'free' software on the IA site, which could be utilized on Commons, like the book viewer, or tools used to convert between individual scans (JP2, JPG, TIFF) and PDF, DJVU amongst other formats?
Another collection on IA (not mentioned so far) that maybe of interest to Commons are the Librivox recordings. Not as much of a priority as Librivox has it's own site and archive IIRC.
WRT formats, we have yet to spot a document in djvu that is not available as a pdf. Oddly there are some that have neither, possibly a transcoding error (example)? --Fæ (talk) 15:20, 23 June 2020 (UTC)
Yes, usually if there's a DjVu there's also a PDF, while the opposite is not true. We generally upload DjVu if available. Most books on the Internet Archive were created when DjVu was still active. The example you link is indeed a case of failed derivation; there are also cases when derived files (OCR etc.) are intentionally not produced, to save resources. Nemo13:35, 25 June 2020 (UTC)
a) A usual transfer where users transfers selected files from IA to Commons?
b) An import where someone go to IA server room and copy their data to a super-monster-huge-storage and then go to WMF server room and connect the super-monster-huge-storage to the servers?
If we are talking about a) then anyone who want to can just start copying whatever they want. If we are talking about b) then someone need to ask the WMF if they have storage ready and talk to IA if they are willing to give us/WMF a copy of their data. --MGA73 (talk) 08:38, 24 June 2020 (UTC)
a) To some extent is already happening on a mid-scale effort by Fæ but others are welcome to pitch in.
b) That was definitely not considered at this point, but if someone else was sufficiently crazy enough to lobby the WMF for it... I also don't think the WMF has ever undertaken any major direct real-world transfers of large content donations from donors.
I would of course still exceptionally strongly object to WMF holding anything that was still "in-copyright" (such as post 1925 items) in a "hidden archive" though. Both WMF and Commons policy has distinctly stated many times it does not want 'non-free' content. ShakespeareFan00 (talk) 09:10, 24 June 2020 (UTC)
From experience of trying to send a USB disk with 100,000 high resolution images supplied very kindly by the Wellcome Library to WMF Ops with their prior enthusiastic agreement, having a disk lost, trying again, giving up after several weeks of trying to get this to work, then using a replacement disk plugged into a personal laptop and uploading using a not-very-reliable home broadband connection over a month instead... it may not be terribly practical to ask the WMF to take responsibility for cloning an image + data dump where volunteers can access it to publish on Commons. --Fæ (talk) 09:27, 24 June 2020 (UTC)
@ShakespeareFan00: Thank you! I just wanted to be sure what the suggestion is.
And as for the "hidden archive" then we have one already. If we want to stop having it then we have to change policy so that once an admin deletes a file it is deleted, gone forever, can't be undeleted. That would be a big change for Commons.
I don't think we have any cases where we on purpose have moved a lot of copyrighted files to Commons to have them deleted. So I agree that if we want to copy copyrighted files in large scale we should make sure WMF won't complain.
But I think that most files before 1925 should be okay. So unless IA mark the files as copyrighted I do not see a big problem for us to import them. Do we have a stat somewhere so we can see how many files they have sorted by year? --MGA73 (talk) 09:39, 24 June 2020 (UTC)
@MGA73: unless IA mark the files as copyrighted As another user said somewhere recently, the IA is having its own problems with copyright right now (in fact, that’s the reason for this proposal), so we probably shouldn’t pay too much attention to their rulings on copyright. Brianjd (talk) 09:50, 24 June 2020 (UTC)
@Brianjd: No one is perfect. If IA say it is copyrighted they could of course be wrong. But I think we should make checks before we copy them and mark them as PD. --MGA73 (talk) 10:03, 24 June 2020 (UTC)
Additionaly, in the period 1870-1925, there are likely to be many many foreign works (including those from places like Mexico which has very long copyright terms. ), whose copyright terms are not Commons Compatible (given that Commons considers origin countries copyright rules as well as the US ones). There isn't a foolproof automatic way to fully confirm non US copyright status from the metadata IA provides at present, and hence why this proposal was originally limited to specifically pre 1870 items. If there was a way to get better metadata, or for Commons contributors to feed more reliable data back to IA (and IA contributors) as well, that should be encouraged. I would hope IA is also considering providing additional 'status' data, as part of it's response to the publishers concerns. Sorry if I sound like I have an "old-curator" mindset here...
Commons has generally been rather conservative about what it considers to have expired copyrights, perhaps more so than even some publishers with fully salaried legal teams! The 'hidden archive' as such only exists because of the persistence and diligence of Commons contributors and admins exercise when removing copyright violations (perceived, potential and actual alike). Deliberately uploading of material that cannot or should not be upload under existing WMF/Commons policy is a different proposition, and I could not support the deliberate uploading of material contributors and admins would know wasn't "compatible". Perma-wiping existing "deleted" items would be a different, lengthy and difficult discussion, although one I think should be more actively considered.
@Fæ: Ooops not good. But if we were are about to clone all the data that IA host then we are talking about a lot more than a USB. I'm not even sure the servers WMF have can store all the data from IA. --MGA73 (talk) 09:45, 24 June 2020 (UTC)
So not too many really, considering 100,000/week is possible for one person using an ancient laptop and a home broadband connection. However we still are finding it highly unreliable to upload PDFs larger than around 200MB, even with many multiple attempts at upload. --Fæ (talk) 09:47, 24 June 2020 (UTC)
P.s. every night while running jobs for User talk:Fæ/CCE volumes, my laptop has spontaneously powered off and lost the tasks, probably due to overheating. It's not really fixable, it's just very old kit. If more folks could endorse m:Hardware donation program/Fæ so an unused WMF laptop might be written off and sent over to get used for these Commons upload projects, it would help me out. Thanks --Fæ (talk) 09:56, 24 June 2020 (UTC)
@Fæ: Thank you. Books are a good place to start. But I think IA also host fotos and videos so there may be much more than books to grab! --MGA73 (talk) 10:03, 24 June 2020 (UTC)
Support I will help with "review" work (with clear instructions), if needed. Books appear to be the priority, but is there any urgency with audio, video and photos? Can an adverse court ruling threaten the complete file contents of The Internet Archive by harming the non-profit corporation and/ or it's Board of Directors? What would be the estimated timeline for this legal process, including appeals? --Tibet Nation (talk) 01:31, 27 June 2020 (UTC)
"Public domain" materials are the priority. 'Books' and 'primary' source documents (such as reports by US Federal Govt agencies) that can be shown to be license compatible with Commons are the focus of efforts, currently.
Commons should not host copyvio, and thus please file detailed DR's if you find something that suggests a work might still be in copyright. (such as evidence in the work, or an entry in authoritative sources like the Catalog of Copyright Entries).
In reviewing (Not an exhaustive list):
All meta-data should be checked against the physical scan. (There have been some anomalies, uncovered by doing this.)
All initial licenses should be checked against evidence in the scans, metadata and other available sources.
All work seemingly published after 1964 is to be assumed copyright, unless determined otherwise, (such as clearly being a work of US Federal Gov.)
All works that seem to be published 1925-1964, should be checked against the Catalog of Copyright Entries, for both an original copyright and a renewal. (Commons can't host works still in copyright in the US, unless it has explicit permissions and licenses).
Works published 1870-1925, of Non-US origin, not in English or without author life-times should be flagged for a more detailed review (Due to URAA interactions, and the extened copyright terms of some jurisdictions.) ShakespeareFan00 (talk) 10:09, 28 June 2020 (UTC)
Works (published in or after 1925) with a primary or substantial contribution by non US authors who died less then 70 years ago, should be flagged for a more detailed review. (Due to potential URAA interactions.)
It's not clear what the full impact of an adverse court ruling could be, but the concern expressed by some is that the cost of paying damages would bankrupt IA, (effectively forcing it's shutdown.) The timescale of the ongoing legal process isn't clear yet.
Propose to make two display improvements for documents. Make the default Commons image display document page user selectable, not just the first page. In the same way as is possible for thumbnails, add a "page" parameter for images in galleries and larger image transclusions so that users are not forced to split out useful document pages as separate files.
A consensus here would make it easier to request a WMF development analysis, in particular as addition to gallery tag syntax and file transclusions syntax would be a global addition.
Case studies:
Case 1 Default.
Case 1 Cover page that should be preferred for the image page.
Addendum: Striking part of this proposal. It turns out that an apparently hardly used feature of transclusions and galleries is the page parameter. Just none of us knew about it or how to use it correctly, probably because mw:Help:Gallery tag does not mention it (which Help:Galleries points to) and the briefly mentioned transclusion option is rather buried at en:Wikipedia:Extended_image_syntax#Page. A task to add a default page to image pages is the scope of this proposal.
Info This seems non-controversial with 100% support, so after a week have now created Phab:T256565 to request the option. As there has been no technical analysis, if folks have suggestions on how best to go about it, please add them on Phabricator. Perhaps someone else would like to mark this proposal as archived? --Fæ (talk) 10:51, 28 June 2020 (UTC)
Neutral I think we all agree that a title page is the best page to display in case of multipage PDF/DjVu documents. Wikimedia software already supports "gallery tag syntax and file transclusions syntax" where one can select specific page of multipage document. Our templates and Wikipedia pages were using them for years. title page number (P4714) used as qualifier on Wikidata or as property on SDC allows storage of the title page number, so various templates can use them. However one think we are missing is a way to automatically determine title page number and mass add title page number (P4714) to large number of PDF files. Alternative approach would be to create a tool to simplify addition of P4714 SDC property. However those tasks do not sounds like a tasks for WMF. I would support any efforts to develop such tools. --Jarekt (talk) 18:27, 6 July 2020 (UTC)
It would be actively damaging and clumbsy for Commons to rely on Wikidata accuracy and availability to be able to display our own media files. Commons needs to be robust enough to work even when links to Wikidata are failing. Functionally and technically, having the title page defined as part of the Commons image display page is the most obvious and robust way of doing it. --Fæ (talk) 18:47, 6 July 2020 (UTC)
Currently title page number (P4714) is mostly used on Wikidata, as a qualifier, but I agree that such data should be stored on Commons as properties of a given file. That is why I think we should be adding title page number (P4714) as SDC property. Any tool that tries to determine title page (arithmetically or by crowd sourcing) number should store it right here on commons. --Jarekt (talk) 19:09, 6 July 2020 (UTC)
This would hide the option in wikitext searches, so again a bad way of doing it. Hiding more and more media file information in "sdc" tags that nobody understands (same as 'captions') and readers can't find is unhelpful. --Fæ (talk) 19:20, 6 July 2020 (UTC)
I can not imagine a wikitext search which wound be relying on title page number, and current search is able to utilize data stored in SDC with "haswbstatement" option. SDC tags are not hard to understand since most wikipedia users are quite accustomed to metadata stored at Wikidata. Just because you do not like to use it does not mean that "nobody understands" them. --Jarekt (talk) 14:27, 7 July 2020 (UTC)
Deluge of logos on Commons
There is an insane amount of logos on Commons. A lot of them are unidentified and uncategorized, a whole bunch more are tagged as own work. A lot of them are not notable businesses and organizations that violate COM:NOT. Does anyone have any ideas how to address this problem? Would a new deletion criteria have some support? For example, a logo uploaded by a new user (under 50 edits), unidentified for longer than a year, and not used on pages is eligible for speedy deletion? Renata3 (talk) 00:28, 19 June 2020 (UTC)
They're mostly spam, as most are from accounts that upload nothing else and have no other edits. Random examples
It's unlikely any proposal for mass deletion or speedy deletion would pass, as many users love spam prefer keeping logos, as they might become useful.--BevinKacon (talk) 11:41, 20 June 2020 (UTC)
Sounds like a job for COM:CSD#G10. My guess is, if that criterion does not apply, then it is not a clear-cut case and therefore a new deletion criterion is not appropriate. Brianjd (talk) 11:49, 20 June 2020 (UTC)
Although an F10 style criteria for logos of obviously non notable firms would be useful, I can't think of a feasible way of making it specific enough for CSD - a speedy deletion criterion should be specific enough that any reasonable user would agree whether a file meets it. ~~ Alex Noble/1-2/TRB21:16, 20 June 2020 (UTC)
Instead of deletion we need to specify what information is required to make them useful. Things that are labelled own work, but are not the work of the uploader are another kind of problem. We probably cannot tell in a speedy way if a firm is notable or not. So there should not be a speedy delete criterion for that. Graeme Bartlett (talk) 13:40, 6 July 2020 (UTC)
Oppose The statement "There is an insane amount of logos on Commons" really strikes me as counterproductive. It would be interested to have a statistic of what number of logos do we actually have in comparison to the organisations with logos. I would be very surprised if we have even 1 permile, which is is "insane" in the sense that they are too few. I would love somebody to begin curating trademark applications and uploading logos which are PD-simple or PD-text. The proposal that makes it more difficult to contribute educationally useful media is... well... "insane". ℺ Gone Postal (〠✉ • ✍⏿) 09:06, 9 July 2020 (UTC)
Increase default number of lines of HotCat suggestion
Oppose I never use the suggestions I only sometimes accidentally click on one. Do not increase the size if there is no option to turn it off. --GPSLeo (talk) 10:09, 2 July 2020 (UTC)
Support changing the default to at least 10, preferably more like 30–50, and increasing the user-configurable range (as described at Help:Gadget-HotCat#User configuration and by Speravir in the above-permalinked discussions) from the current 5–30 (which I have just experimentally confirmed) to 0–50 or greater, which I hope will satisfy MPF (who asked for 50) as well as GPSLeo and Donald Trung (who appear to want 0). ← PointyOintment ❬t & c❭19:20, 17 July 2020 (UTC)
Support default 10, and user-configurable range 1-50 (presumably '0' would disable Hot Cat altogether?!). Also make user configurability options conspicuous and easy to set (i.e., a tickable menu, not to have to add a line of strange code to a weirdo page with worries of what else that might unwittingly do) - I've been using Hot Cat for best part of a decade, yet only found out about the user options a month ago, and they weren't easy to set. - MPF (talk) 20:02, 17 July 2020 (UTC)
@MPF: presumably '0' would disable Hot Cat altogether?! I had intended 0 to mean that suggestions were disabled, but you could still use HotCat by typing in a full category name. (Maybe, if there is only one possible suggestion for what you've typed in, it would still suggest it in the entry box, as it does currently.) I agree about having a GUI for settings (like the one Cat-a-lot has, perhaps), but I think that should just be a feature request. ← PointyOintment ❬t & c❭23:07, 25 August 2020 (UTC)
In my opinion list type view is not well suited for commons but for search engines like Google/Bing or encyclopedia like Wikipedia. It's not easy to find the image that I am looking for on commons, lists can't display more files than grid view. If you want to compare images you are forced to use the galleries/categories, new users/unregistered are usually unaware of categories / galleries. And you know what, we don't have categories or galleries for every possible search. There's also a lot of text on search results (on commons) which is utterly useless, I'm not criticizing the developers (Sorry, if you think so.) this was implemented a long time ago.
Please use *{{s}} ~~~~ to support or *{{o}} ~~~~ to oppose. Please add reson for oppose or support.
Support As long as all of the information that's currently available about the item is still available (I use most of it often, and these other services often seem obsessed with showing as little as possible) and the grid is uniform and not irregularly sized (another thing image services like to do that only makes sense if you're showing only the image). On my 1920x1200 monitor search only utilizes a fraction of the screen space, so it would be nice to take advantage of the rest. – BMacZero (🗩) 17:43, 8 June 2020 (UTC)
Oppose but it's good to have as an option. I use that "useless" text much more often than looking for images, when you are searching for categorization reasons. Carl Lindberg (talk) 05:32, 10 June 2020 (UTC)
As long as it clicking on an image at the current implementation of grid view at Special:MediaSearch takes me to the file description page (which is annoying and not how image search on Google works), I oppose making grid view a default option for images, and I strongly oppose it as the default view for all namespaces in case that's what the proposal is about. I might consider supporting it as the default view for images if my concern is solved. Note that I don't oppose making this an option/opt-in. --pandakekok906:09, 10 June 2020 (UTC)
Neutral/Weak support as long as "power users" are given the option of switching to old-style-search through their preferences. If images took a little bit less time loading, I'd totally support it. Strakhov (talk) 22:12, 18 June 2020 (UTC)
Neutral. if and only if Special:Search is retained and directly reachable. I don't care what the default is, but it needs to be an easily-controlled option. If all I want to do is find an image with a certain look, this is conceptually a decent way to do it. But having images different sizes or croppings is a problem (gives undue visual weight based on certain dimension details of the original), having it be infinite-scroll and all sorts of other dynamic effects are likewise usability problems for me--so Special:MediaSearch is unacceptable in its current form. But I want to see all those source snippets too. Current Special:Search lets me see the source snippets I often care to see at least as much as the image. And I can choose how many to see and bookmark where I am in the results for future reference if I'm workint through a list for some purpose. DMacks (talk) 21:10, 2 August 2020 (UTC)
Votes to enable grid view as an opt-in or as an optional feature
Support as a "visual display" toggle in the search and results pages. I don't want it, but if it has user demand and developer support, no objection to making it avaialble to those who want it. But it's fundamentally a problematic approach for me in terms of concept and usability/implementation, so best to leave users in control. DMacks (talk) 21:14, 2 August 2020 (UTC)
Strong support Gee, I've been waiting for my entire Wikimedia career for someone to propose this! It is much easier to see and navigate! Thank you to whoever propose this! Barnstar incoming! Regards, Jeromi Mikhael(marhata)11:45, 19 August 2020 (UTC)
Support. Also please add the posibility to sort on upload date (most recent files first), and maybe on file size and image size too. Eissink (talk) 12:10, 19 August 2020 (UTC).
In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. -- Eatcha (talk) 14:16, 5 June 2020 (UTC)
Comment, this should be optional, discoverability is an issue on Wikimedia Commons, but the current list search, while not perfect, is best for searching for categories, galleries, and templates, as well as various other types of pages, while Wikimedia Commons exists for its media, pages like "{{PD-USGov}}" should be easy to find. Personally I think that we should incorporate more "search features" into the website itself, such as a "view all" option for categories and an option to also add files from sub-categories to this, solutions like these would make searching easier. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:49, 7 June 2020 (UTC)
It appears that most users hate Special:MediaSearch beacuse it's not similar to Google's or beacuse we have files other than media(images,videos,sounds) and grid isn't ideal for searching pages/templates. I am adding a new proposal for enabling the prototype as opt-in feature. Thanks for your valuable inputs. -- Eatcha (talk) 08:24, 10 June 2020 (UTC)
I don't understand how we can discuss enabling a feature which doesn't exist yet. How am I supposed to know whether I'll like it? Even if you agree with the general idea, there are millions of ways to do it wrong. Nemo14:41, 30 August 2020 (UTC)
Turn MOTD into MOTW
Since Commons cannot churn out one featured video (FV) a day, I suggest to turn Media of the Day (MOTD) into Media of the Week (MOTW). The current problem is that some MOTDs are of low quality not becoming of the Main Page. Even we can't write English captions for all of our MOTDs. The solution is to focus on quality rather than quantity. Each week we can show high-quality featured videos with captions in English and hopefully many other languages.
Comment The main page gets around 125 thousand views in a day, in comparison en.wp's main page gets 5.5 million. It asks a lot of the small community to maintain and select the content on a daily basis and give it all a meaningful review or vote (thereby avoiding manipulation by disposable sock accounts), so moving MOTD to a weekly cycle makes a lot of sense. Thoughts from those active in maintaining the main page should carry significant weight in this consensus. --Fæ (talk) 09:40, 1 June 2020 (UTC)
Oppose strongly. motd need not be featured videos. there are certainly more than 365 high quality, free videos that are produced in the world or expire into pd each year.--Roy17 (talk) 09:53, 1 June 2020 (UTC)
Commons may have enough content (I have my doubts), but certainly does not have the manpower to present them all in a neat way. Just in the previous month four MOTDs went to the Main Page without English captions. Although they had French captions, English captions can be read by many more people. See Template:Motd/2020-05. 4nn1l2 (talk) 10:11, 1 June 2020 (UTC)
I had seen that but I was not sure what the consensus was and I was concerned to avoid antagonising the uploader. Have added English captions to his June MOTDs. — Racconish💬10:38, 1 June 2020 (UTC)
Further comment. I am a little concerned about giving too much importance to technical considerations as opposed to historical, documentary or merely educational value. We do have a handful of contributors who do use the venue to show some of their own productions which might not always meet EV criteria, but I think we should be very careful in establishing formal criteria, if there is a consensus to go that way, in order to preserve the highlight on diversity. — Racconish💬10:05, 1 June 2020 (UTC)
Support in principle. We theoretically have enough high-quality media to feature one a day, yes, but in practice we do not have enough volunteers to curate it on a daily basis. I agree with some reduction in frequency, but 7x might be a bit drastic. One every 2-3 days would be the sweet spot, but I'm not sure how to name such a thing. -- King of ♥ ♦ ♣ ♠15:37, 1 June 2020 (UTC)
Alternative suggestion: We currently are promoting FPs at a rate of 2-3/day, so most of them will never have their time in the spotlight. Since "media" technically includes images, perhaps we can alternate between days with an FP in MOTD (i.e. running two FPs at once) and days with a video/sound/other in MOTD? -- King of ♥ ♦ ♣ ♠15:44, 1 June 2020 (UTC)
Another suggestion: let's take a real recent situation, {{Motd/2020-02}} + {{Motd/2020-03}} and look at it carefully. I see no void there, therefore no evidence the daily rythm is problematic. But I am sure we can evidentiate some problematic nominations or template issues (not in English, without wikilinks, etc.), and then try to avoid these problems by stating some guidelines for nominators. In an nutshell, I think what we might need are simple guidelines. — Racconish💬17:05, 1 June 2020 (UTC)
Neutral I If we have enough volunteers to curate MOTD for each day, than by all means lets do it, but I am also fine with reducing the frequency or allowing FP to be included in MOTD. --Jarekt (talk) 18:05, 1 June 2020 (UTC)
I dont get any of the arguments here.
1. not enough FV
no, motd dont need to be FV. many videos or audio files are not selected for the little known FV—I never give a damn and I'm sure many ppl dont care either—but that doesnt mean they are low quality.
2. no english caption
captions need not be english. I dont care if it's french czech or polish. none of them are my native. very rarely would i see a caption in my native, and even if someone wrote it i wouldnt find it coz i use the english UI. Commons doesnt prefer any language. I dont care much about the captions either. it's motd not caption of the day. i can enjoy a video even if nobody summarises it. if i find it interesting but not understand the language i could find out more by looking at its source.
3. not enough volunteers
that's factually wrong. I know for a fact that there are always czech polish and Erzya users adding captions timely for the past one year. what you are complaining is that sometimes the english caption is not added in time, or that you dont like the video/audio file chosen.
Solution for your actual problem: Take it upon yourself. Add the caption yourself. Select videos you like yourself. Challenge the ones you dont like on VP yourself.
365 motd a year is not too much but actually not enough. if the world is divided into subnational first-level units, there're several hundred (50 states of US, regions/provinces of france/germany/spain/china/india etc.). each region can only have motd less than once a year. if every 10 million ppl (roughly the population of sweden/belgium/cuba/jordan/UAE) were to have one motd, then the queue would be two years.--Roy17 (talk) 11:28, 2 June 2020 (UTC)
Comment A weaker proposal: How about making FP sets eligible for MOTD? They were featured as a set for a reason, because they work better together than individually. As such, they don't really belong in POTD: either you include everything and it's not really a "Picture (singular) of the day" or you have to choose one of them, diminishing the value of the set. A set is effectively an interactive slideshow, which is more appropriate for MOTD than POTD IMO. The word "media" has the nice property that it can be singular or plural. -- King of ♥ ♦ ♣ ♠20:42, 4 June 2020 (UTC)
Can't we have both? Media of the Day has 365 (three-hundred-and-sixty-five) different media files, reducing this to 52 (fifty-two) would greatly reduce the diversity of files presented, I know, that's the proposal, it's better to have a few quality files than a lot of lesser quality files, but higher amount of files can better showcase the great range of media files present on Wikimedia Commons. Perhaps the MOTW can be located on the top and we'll move the MOTD to the bottom, where those that check out the main page can still see a different MOTD every day, while the more excellent files would be located front and centre above. Those who are interested enough in Commonswiki to begin with will simply scroll down. Short low quality videos that showcase "science in action" or peculiar animals that currently make it to the main page tickle my interests, so I'm not a fan of removing them, while allowing fot the continued existence of the MOTD will let there be "more winners" thus more people that will look for "maybe not the greatest, but certainly the most interesting and educational" type of videos we have now. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:04, 5 June 2020 (UTC)
I'm not in favor of having two audiovisual files on the main page when we only have one static picture. Like it or not, the vast majority of our content (featured or otherwise) is pictures, and putting up even more AV media on the main page (417 a year) isn't what we should be aiming for IMO. -- King of ♥ ♦ ♣ ♠13:10, 5 June 2020 (UTC)
Support Changing MOTD to MOTW. The current daily release is clearly not working this month and even in the months prior not all of the english captions where filled. Some change is needed, keeping the status-quo is not an option.--Snaevar (talk) 15:23, 4 July 2020 (UTC)
Support I think the week time period will also allow for actual discussion on the media as well. I don't think we necessarily need a requirement to have featured media be a criteria at the moment but that can be considered later. -- Ricky81682 (talk) 19:39, 5 July 2020 (UTC)
I think what we can do is always favor FV over other videos. So if FVs are getting promoted at a rate of faster than 1/week, then FV will become a de facto requirement. If the rate is less than that, then we can supplement FVs with suitable videos chosen by consensus (which the slower process will allow more time for). -- King of ♥ ♦ ♣ ♠05:19, 6 July 2020 (UTC)
Oppose Media of the Day serves two purposes: 1) To recognise uploads 2) To stimulate new uploads. If somebody sees something on the main page that is "not becoming" of a main page, then it can and should challenge them to upload something better. Also I feel that a main page is just another page of the project. It is a special page only because it should welcome somebody here, but it should not be special in ways that make it into a separate project. We host media that is shown on the main page, and that is good. ℺ Gone Postal (〠✉ • ✍⏿) 08:57, 9 July 2020 (UTC)
We all agree that MOTD is better than MOTW if we can manage it, but the problem is that there is not enough labor to support a daily update. Forget quality; we can't even ensure that the MOTD template is updated with anything at all, as the incident on July 4 showed. -- King of ♥ ♦ ♣ ♠19:36, 9 July 2020 (UTC)
I was quite shy about nominating things for Media of the Day, but I guess I should not be. I will be keeping an eye on things from now on. ℺ Gone Postal (〠✉ • ✍⏿) 13:50, 16 August 2020 (UTC)
How many times in history has an MOTD been created only after that day? Could the perceived lack of curating effort be a result of the pandemic? Can those saying lack of manpower provide some stats on the actual problematic MOTD entries from 2009 to now?--Roy17 (talk) 20:38, 18 July 2020 (UTC)
Oppose. There are a lot of media which has high quality and meaningful message and they should posted at the mainpage to allow more people to watch them. MOTW are absolutely not enough.Yolopertz (talk) 00:47, 19 July 2020 (UTC)
Comment: Weekly means one-seventh of Daily. It is a huge decrease. Maybe daily is too frequent but weekly is too few.—-Hoising (talk) 10:57, 19 July 2020 (UTC)
On the other hand, since AF228 and an invisible AF prevent non autopatrolled users from creating description templates, why not extend it to any potd/motd templates? Then you dont have random people creating new entries. Another problem solved.--Roy17 (talk) 00:09, 19 July 2020 (UTC)
We need to resurrect participation
Just to let people know, I have began to actively participate in Media of the Day process. It is actually lots of fun. Currently until 9th of October there is only a single gap. And I think it is good to have gaps, for cases where there may be a topical file that should be "streamlined". I think that the process itself needs some work, but making it weekly rather than dayly actually won't help all that much. ℺ Gone Postal (〠✉ • ✍⏿) 03:20, 15 September 2020 (UTC)
It is not the job of Commons to project or protect intellectual property claims of file uploaders
It is confusing to have works on a free media site with titles that may appear to contradict the terms of our licenses
We don't know (nor should it be our responsibility to know) whether a name or work actually has the registration signified by the mark
Trademarks and copyrights lapse or expire eventually, so the use of the mark eventually becomes inaccurate for all of them
Removing them reduces the instances of otherwise unnecessary title elements that are difficult for users to type on a standard keyboard
Unless there is already a rule to this effect of which I am unaware, this seems like a common-sense approach to me. BD2412T16:13, 26 June 2020 (UTC)
Support Provided that actual "copyvio" material (such as non-free logos or incompatibly licensed media) is removed at the same time. ShakespeareFan00 (talk) 17:50, 26 June 2020 (UTC)
This has nothing to do with whether the content of the file is subject to trademark protection, only whether the itinerant symbols should be used in filenames. BD2412T22:12, 26 June 2020 (UTC)
Oppose It is the job of Commons to denote the intellectual property claims of file uploaders; that's why we put a proper license on works. Likewise, copyrights lapse on all these licensed works, but we still include the licenses on the page. I'm not seeing the value in mass file renaming, given our usual restraint in file renaming.--Prosfilaes (talk) 22:23, 26 June 2020 (UTC)
It seems that quite often the symbols use in the file names do not correspond to any actual intellectual property claims of file uploaders, much less the proper license for the work. BD2412T22:45, 26 June 2020 (UTC)
Not sure that would be a great policy, but not strongly opposed.
It's not the job of Commons, but it might be the job of the uploader.
None of them contradict any of our licenses. Trademark-related symbols are completely unrelated, and copyright symbols simply state that copyright exists, which is necessary to license it. PD files don't need them, of course.
The uploader might know. Removing them may seem to indicate we don't think they are accurate.
Trademarks don't necessarily expire. They can be renewed indefinitely (but must be renewed fairly frequently). Removing copyright symbols for PD works, sure.
This seems like a reasonable concern. On the other hand, filenames can be any language, and languages in non-latin scripts (or even accents) can also be just as hard to type, and we should not be touching those without reason.
I would definitely try to avoid these characters when constructing filenames from source text -- it seems like the Panoramio examples might be instances of that. But if an uploader intentionally puts one there, not sure it should be policy to remove them. You might even claim that it is removing copyright-protection information. Carl Lindberg (talk) 23:04, 26 June 2020 (UTC)
Support Changing existing files except if and only if that information is moved to the file description page and Support blacklisting those symbols in file names for future uploads. Frankly, if it's not something that can be typed on keyboard by your average user (accounting for that different countries include different characters on basic keyboard layouts), it shouldn't be in a file name, because it unnecessarily hampers re-use. A file name is also not an appropriate place to store copyright/license information, that's what the description page is for. The Squirrel Conspiracy (talk) 05:46, 27 June 2020 (UTC)
These symbols are always going to be misleading to some extent. Copyrights and trademarks not only expire eventually, but are also jurisdiction-specific. A term may have a trademark registration that is valid only in Korea, or only in Peru, or only in Iceland, and is invalid in the rest of the world, or even claimed by someone else in another country. At some point, they will mislead. BD2412T14:39, 27 June 2020 (UTC)
Support It is somehow copyrighted and I see no reason to include it in the title. BTW, I like the proposal made by King of Hearts. --A1Cafel (talk) 16:55, 29 June 2020 (UTC)
Should be written in guidelines for good file names, but should not be an automated filter or renaming reason. --GPSLeo (talk) 08:38, 30 June 2020 (UTC)
Because it is just a minor style problem and nothing that should force creating redirects with all the problems redirects have. I do not want automated filters because sometimes these symbols might be useful to describe the content and I do not want to start blocking symbols because that would open discussions on blocking of many more symbols too. --GPSLeo (talk) 12:37, 30 June 2020 (UTC)
Oppose too disruptive for little benefit. Points 1, 3 and 4 are actually arguments saying we should not pay any attention to it. Separate proposals for each character would be less disruptive.--BevinKacon (talk) 16:36, 30 June 2020 (UTC)
Oppose Most licences require you to preseve copyright notices. For example, you can find the requirement in all Creative Commons licences with the "BY" attribute. If we remove copyright notices from file names, there's a risk that we accidentally violate the licensing terms. --Stefan2 (talk) 22:42, 30 June 2020 (UTC)
Is it possible to make the presences of these characters a warning when trying to use them, which requires a specific override step to make sure you really wanted them? Like you get when trying to upload over the same file? Carl Lindberg (talk) 00:31, 1 July 2020 (UTC)
Oppose It somewhat makes sense to have a clickthrough when one uploads the file with such symbols offering to 1) remove them 2) substitute them for '(c)' '(r)' and '[tm]' or 3) keep them as is. I would definitely oppose mass renaming, especially since I really hate .jpg extention that is automatically applied to .jpeg uploads during the rename. ℺ Gone Postal (〠✉ • ✍⏿) 07:09, 2 July 2020 (UTC)
Oppose, on generic (censorship) and specific (licensing) basis. And let’s get rid of the ban on SMP characters, where are located those pertaining to CC licenses. -- Tuválkin✉✇21:42, 4 July 2020 (UTC)
Support as a warn+confirm/override for cases where the image really does represent the symbol itself. In WP articles, we often see these symbols used for the underlying subject or name, not a specific portrayal of it. The symbol is thus unclear whether it applies to the file itself, the object in the image, the nonvisible details hidden within the image, or the term used to identify it. For example, consider a picture of a colorless liquid that is a IV solution of a drug: the image is copyrighted by the photographer, the drug-name is trademarked by the company, the drug is patented by the company but invisible in the liquid, and the label and package are too plaintext/utilitarian to be protected. PR flaks write the (R)/(tm) next to the drug-name every time they write it, but that's the *least* protected among the aspects of this image. Better to have the title be more direct and leave it to the Description to identify the various levels of licensing. Also, these details might be transient ((c) and (tm) can lapse), which means these filenames have an expiration date. DMacks (talk) 06:46, 27 July 2020 (UTC)
You do realise that this proposal still would allow the user to put "(c)" or "(r)" in the file name. Like I have said, this is a solution, that looks for the problem, finds one, but does not resolve any part of that problem. In other words "Somebody uploads files to Commons, and they are doing it in the second best way, let's anger uploaders, better for them to contribute nothing". ℺ Gone Postal (〠✉ • ✍⏿) 04:25, 31 August 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. 1989 (talk) 20:54, 25 August 2020 (UTC)
Support I support importing books to Commons as long as we are sure that most of them are in scope and there are no copyright issues. The suggested approach above gives me no reason to worry. So it's a go from me.
Strong support, I've imported many individual books from the Internet Archive in the past and have always hoped that this community would one day mass-import Internet Archive books, if Wikimedia Commons would want to be taken seriously as "a public domain library" such an import is a must, and more importantly it would also preserve this knowledge online in case it might be lost forever. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:15, 20 June 2020 (UTC)
Question Just to be sure. Are we talking about
Info This seems non-controversial with 100% support, so after a week have now created Phab:T256565 to request the option. As there has been no technical analysis, if folks have suggestions on how best to go about it, please add them on Phabricator. Perhaps someone else would like to mark this proposal as archived? --Fæ (talk) 10:51, 28 June 2020 (UTC)
Neutral I think we all agree that a title page is the best page to display in case of multipage PDF/DjVu documents. Wikimedia software already supports "gallery tag syntax and file transclusions syntax" where one can select specific page of multipage document. Our templates and Wikipedia pages were using them for years. title page number (P4714) used as qualifier on Wikidata or as property on SDC allows storage of the title page number, so various templates can use them. However one think we are missing is a way to automatically determine title page number and mass add title page number (P4714) to large number of PDF files. Alternative approach would be to create a tool to simplify addition of P4714 SDC property. However those tasks do not sounds like a tasks for WMF. I would support any efforts to develop such tools. --Jarekt (talk) 18:27, 6 July 2020 (UTC)
Oppose The statement "There is an insane amount of logos on Commons" really strikes me as counterproductive. It would be interested to have a statistic of what number of logos do we actually have in comparison to the organisations with logos. I would be very surprised if we have even 1 permile, which is is "insane" in the sense that they are too few. I would love somebody to begin curating trademark applications and uploading logos which are PD-simple or PD-text. The proposal that makes it more difficult to contribute educationally useful media is... well... "insane". ℺ Gone Postal (〠 ✉ • ✍ ⏿) 09:06, 9 July 2020 (UTC)
Done changed it from 5 to 10. Multichill (talk) 13:21, 7 August 2020 (UTC)
Weak support as long as "power users" are given the option of switching to old-style-search through their preferences. If images took a little bit less time loading, I'd totally support it. Strakhov (talk) 22:12, 18 June 2020 (UTC)
Comment, this should be optional, discoverability is an issue on Wikimedia Commons, but the current list search, while not perfect, is best for searching for categories, galleries, and templates, as well as various other types of pages, while Wikimedia Commons exists for its media, pages like "{{PD-USGov}}" should be easy to find. Personally I think that we should incorporate more "search features" into the website itself, such as a "view all" option for categories and an option to also add files from sub-categories to this, solutions like these would make searching easier. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:49, 7 June 2020 (UTC)
.jpg){kind=link}
