Commons:Village pump/Proposals

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

Shortcut: COM:VPP· COM:VPPROP


  Welcome to Commons   Community Portal   Help Desk
Upload help
  Village Pump
copyright • proposals
  Administrators' Noticeboard
vandalism • user problems • blocks and protections
 
Commons discussion pages (index)


Welcome to the Village pump proposals section[edit]

This Wikimedia Commons page is used for making proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Commons:Village pump, which handles community-wide discussion of all kinds. Discussions here should be of wide interest; those which are more specific may be moved to the main Village Pump, with a note left here. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. For old discussions, see the Archive. Recent sections with no replies for 14 days may be archived.

  • If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing please do not comment here. It is a waste of your time. One of Wikimedia Commons' basic principles is: "Only free content is allowed." This is just a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  • Have you read the FAQ?
  • For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump.


Preventing the use of non-existent categories with UploadWizard[edit]

The UploadWizard can be used to add non-existent categories. Can the upload process be modified to alert and/or prevent non-existent categories from being added to an uploaded file? Alan Liefting (talk) 17:27, 5 December 2014 (UTC)

I thought there is some grey text saying something like This category does not exist and will be created when entering a name of a category that does not exist. Is this gone? -- Rillke(q?) 17:35, 5 December 2014 (UTC)
I have not actually checked the wizard to see how it works but this file was uploaded today with a couple of non-existent categories. Alan Liefting (talk) 18:12, 5 December 2014 (UTC)
Yes, there is a warning that a particular category does not yet exist. However, regarding Alan's suggestion, I'm not sure it's a good idea to prevent nonexistent categories from being entered. As an experienced editor, I sometimes put such categories in first, and then create them once the upload process has been completed by the wizard. — SMUconlaw (talk) 20:27, 5 December 2014 (UTC)
Exactly my thoughts. (But of course why would an experience editor be using the UploadWizard at all, that’s another matter.) -- Tuválkin 13:55, 6 December 2014 (UTC)
Because it's easier to use UploadWizard to upload a number of files in a batch rather than to upload them singly, of course. — SMUconlaw (talk) 20:45, 23 December 2014 (UTC)
Adding categories that should exist is fine, and something I would expect from an experienced editor, but users without experience often add categories that will never be created. To improve things around here and to reduce the editors workload I think we need to have the UploadWizard reject non existent categories. Alan Liefting (talk) 18:47, 20 December 2014 (UTC)
Yeah, it is not obvious to me that we would benefit from that move. It seems to me that allowing non existent categories would be helpful for newbies to at least give us some idea of how to categorize. It might me easier in many cases to fix a wrong category name than guess categories on an uncategorized image. --Dschwen (talk) 21:51, 5 December 2014 (UTC)
Hoe a file is categorised should be able to be determined from the description. Unfortunately the description is not always very descriptive. Alan Liefting (talk) 01:34, 6 December 2014 (UTC)
You understand that for most purposes and in most cases, a file description is meaningless boilerplate, yes? -- Tuválkin 13:55, 6 December 2014 (UTC)
Once uploaded the correct categories can be added easily with HotCat. Alan Liefting (talk) 18:48, 20 December 2014 (UTC)
This is true for your uploads. However not for those of other users and we're thrilled that we would end up without any description of the file at all if we're going to dismiss non-existing categories. -- Rillke(q?) 18:53, 20 December 2014 (UTC)
Should we reject files that do not have an adequate description? Alan Liefting (talk) 19:03, 20 December 2014 (UTC)
Perhaps when our tools are able to identify (in)adequate descriptions, i.e. not for many years. Even then there are many good images with obvious subjects but without description. What about "unidentified plant.jpg" described as "unidentified plant". Once somebody identifies it, file name, categories and description can easily be modified/added (of course location etc. would have been good to have, and some plants are difficult to identify from a photo - but would we rather refuse the image? See e.g. File:Plants on swamp.jpg).
My experience with non-existent categories is mostly about categories with names in the uploader's mother tongue or similar, which are easy to correct or use for adding to the description (for those who know the language, which often is related to the subject). I myself often have difficulties to find categories for things I usually do not discuss in English - what about those who do not master English at all?
--LPfi (talk) 18:44, 21 December 2014 (UTC)
No, let users upload stuff, this is technically hard enough. Whatever it is could be automatically tagged as "needs author + category + date + description + license + source" flipping to speedy self-destruction after one day. Spammers thinking that they found a free one day (pron or warez) hoster have to be blocked indefinitely, they'd need new accounts daily, but would that be worse than it is? –Be..anyone (talk) 01:54, 22 December 2014 (UTC)

No more lo-res preview while picture is loading, please![edit]

For a while now, pictures on the Commons have been displaying a low resolution preview, for the 2-3 seconds or so it takes (on a normal connection) for the picture to load fully. This is actually REALLY annoying and tiring for the eyes. Personally I find absolutely no need to see a blurry preview while I wait for the picture to load, given that the "wait" is only a few seconds anyway. I think it'd be really good to scrap this algorithm and just have the pictures load normally, as on any other website, i.e. without that useless&iritating preview. Thanks! — Preceding unsigned comment added by 192.167.90.244 (talk • contribs) 10:27, 10 December 2014‎ (UTC)

If you are talking about Extension:Media Viewer, please report it at Phabricator as we have no control over this piece of software. -- Rillke(q?) 14:17, 10 December 2014 (UTC)
Example, please, for a few days I'm still on the "GPRS speed, like ISDN" variant of my mobile broadband plan (after eating up the 5GB per month with a remotely acceptable bandwidth.) Only a few seconds for you could be almost an hour for me in this state. –Be..anyone (talk) 14:26, 11 December 2014 (UTC)
I guess it's about the low-res version MediaViewer presents first, which it takes from the thumbnail that is shown on the page anyway, not about interlaced PNG. -- Rillke(q?) 14:31, 11 December 2014 (UTC)
Simple solution:don't look at it!! Sardaka (talk) 07:36, 26 December 2014 (UTC)
Ah yes, the Wikimedia version of slut shaming. Always blame the person for what they did not the system. Saffron Blaze (talk) 00:07, 27 December 2014 (UTC)

Allow .ico files to be uploaded[edit]

On one of the perpetual everything wrong with commons threads on wikimedia-l, there was a comment about supporting .ico files [1] (ping User:MZMcBride). These types of files are used as a general icon format on windows, and as the favicon for websites (e.g. https://commons.wikimedia.org/favicon.ico ). I wasn't aware that anyone actually wanted this. If people actually want this (By which I mean, there's a vote which I can point to as "Community consensus"), I think it would be very trivial to get the change through the technical bureaucracy. So, do folks here want to enable uploading of .ico files? (To be clear, MediaWiki would probably render thumbnails of these files as pngs). Bawolff (talk) 07:41, 16 December 2014 (UTC)

ICO is a seriously complex container format for some kinds of BMP and PNG (ffmpeg has it as "muxer", not as "encoder"), please don't waste your time for this incomprehensible Windows crap. Support XPM if you're looking for missing formats. Yes, I'm a Windows user.:tongue:Be..anyone (talk) 09:20, 16 December 2014 (UTC)
image magick already supports it (At least it worked with the one file I tested. Haven't done extensive testing), so the amount of effort needed would be really minimal (XPM would also be similarly easy if we wanted that format). Yes, an ico can contain multiple icons (normally a single icon in multiple sizes and possibly colour depths), my initial idea of support was the lazy version, that is: ignore all but the biggest version. Or perhaps, the different sizes in the icon file, could be treated like different pages in a pdf, or it could be treated as a totally separate thumbnailing parameter if need be. Now that I think about it, I kind of like the multi-page approach. Anyways, my point is that all the heavy lifting is already done by image magick, all that's needed is a tiny bit of glue code for MediaWiki. The question to answer is if .ico support would be a net gain for commons. Bawolff (talk)
Do we have a process of benefit:cost analysis? Okay, benefits: Apparently, we have some icon categories with, according to CatScan, 171700 icons, and sometimes it would be handy to download a fully-featured icon instead of PNGs which one has to compose together to a icon file requiring expertise (true colour/ high colour/ 256 colours support, icons of which sizes [control panel, start menu, windows vista+, ...]) and software. Cost: Development (I guess a new Bitmap handler or similar must be written) but if ImageMagick supports the ICO format, it won't be too much (as no legal/ security review would have to be involved). Possible disadvantages: Multi-page stuff is a little harder to patrol. If we only see the highest resolution thumbnail, we might miss something but it's not a lot different from thumbnails embedded in JPEG metadata. All in all, I would Symbol support vote.svg Support this development if Bawolff has plans about that development as the human and maintenance aspect is utterly important for proper working software in volunteer driven projects. However, I don't see windows icon support as a first-class priority. -- Rillke(q?) 11:43, 16 December 2014 (UTC)
Facilitating customisation of eyecandy on proprietary platforms seems pretty far from Commons:Project scope. There are many other things desperately calling for resources. LX (talk, contribs) 19:57, 16 December 2014 (UTC)
Re User:Rillke: Yes, I'm volunteering to do the relavent coding stuff. Re User:LX: I don't disagree. This is just something that would be really quick to do. So if it would be useful, we should do it, as it takes almost no resources. The question of course is if its useful. Bawolff (talk) 21:46, 16 December 2014 (UTC)
"complex container format" suggests to me the possibility that malicious code could be hidden in that container, IANAP (not a programmer). What do you experts say to this? --Túrelio (talk) 21:26, 16 December 2014 (UTC)
I do not think that's a risk for the .ico format (Note that there's a related format called .icl, which probably would have risk associated with it). The container format is much simpler than many modern container formats, and is basically just an index at the beginning listing how many images are in the file, and what size, followed by all the images smushed together. Bawolff (talk) 21:36, 16 December 2014 (UTC)
No security issues, remotely the same idea as TIFF. –Be..anyone (talk) 22:04, 16 December 2014 (UTC) Update: There could be a legal issue (I'm not aware that ICO is open source), and a support issue (works with ImageMagick x.y does not imply works with version u.v. or Windows a.b). –Be..anyone (talk) 19:57, 17 December 2014 (UTC)
The main concern when writing MediaHandling extension is always to get thumbnails :) And with ImageMagick being available on production servers, there is. Windows should know the icon format very well; provided they are properly created, they should just work under Windows. MediaWiki will not touch any file data; never did this for uploaded files. If you download the "full resolution" you always got the original as uploaded by the uploader, if this is what you were wondering about. -- Rillke(q?) 23:11, 17 December 2014 (UTC)
There is an open source implementation of a decoder for that format in image magick. From a copyright perspective we should be fine. From a patent perspective, IANAL, but I doubt there's anything patentable in that format (Then again, software patents are always surprising), additionally, the format is over 20 years old, so if there were software patents, they'd be expired. So the format should certainly be considered free. Bawolff (talk)

Tracking project for Commons on Phabricator[edit]

Phabricator is our new issue and feature request system. It replaced Bugzilla about a couple of weeks ago and it's a lot more flexible regarding to which project a task is in, allowing, for example multiple projects. In phab:T802 it is suggested to create such projects on Phabricator.

From my point of view, this would have a couple of advantages for us, especially those who care about reporting issues there:

  • Improved tracking of "our issues" and feature requests -- If something was broken recently one could quickly look up the newest issues for Commons and this way find a way around the issue or determine whether one has to create a new issue report.
  • We could invite people to report issues their own, centrally, under the Wikimedia Commons project, this especially given the fact that it's possible to login through oAuth with a SUL account now. Interested parties could watch new incoming issues, translate and categorize them, or reject if local administrators are responsible for that issue. This means, issue reports are hopefully not scattered around various places but could be more centralized and the learning curve to the issue tracker is not so steep and we possibly ease and improve participation in Phabricator. More participants also means that developers will less frequently ask people to "prove" the issue exists (e.g. asking for screen recordings etc.; of course developers must be still able to reproduce an issue but they'll be less sceptical if they don't get the reports from one and the same person all the time).

Before, in Bugzilla, we achieved this with tracking bugs (tasks). But it was a little fiddly to do this for huge projects and Commons is huge. -- Rillke(q?) 16:46, 20 December 2014 (UTC)

{{Discussion menu}} had a link to recent bugs related to commons, hopefully that can be revived in 2015. –Be..anyone (talk) 17:22, 20 December 2014 (UTC)
Do we really need a proposal? Wikidata have its own project: https://phabricator.wikimedia.org/tag/wikidata.org/ - so it shouldn't be a problem for commons. --Steinsplitter (talk) 18:57, 20 December 2014 (UTC)
I am just interested in people's concerns and opinion :) -- Rillke(q?) 20:52, 20 December 2014 (UTC)

Proposed modifications to Gadget-Stockphoto[edit]

An editor posted to the help desk, stating that reusing media from the Commons on non-English Wikis is cumbersome as the output of the Use this file link always outputs a string with the File: prefix, whereas wikis in languages other than English use different prefixes. For example, Czech Wiki uses Soubor instead of File, although using File still works, for non-English speakers this could be confusing, and not having the output in a selected language does go against the multilingual tenets of Commons a little. I therefore ask that the prefixes of the links that Gadget-Stockphoto outputs be in the users selected language, not English.

It also seems that the output only uses the filename as the description. Is it possible for the gadget to retrieve the description from the media's information template (preferably in the users selected language)? Thanks for considering these proposals. ColonialGrid (talk) 16:32, 22 December 2014 (UTC)

It was a mistake in the first place to allow localization of the file syntax as part of the Wiki-Markup. Since this is, AFAIK, a configuration thing, it would be probably wrong to localize the namespce when displaying on Commons. Asking @GDubuc (WMF), Bawolff, Fabrice Florin (WMF): I suggest to turn the gadget completely off and ask the Multimedia Team to develop a replacement for which they've anyway developed the libraries in course of creating Media Viewer so this shouldn't be too hard to tackle for them. -- Rillke(q?) 17:59, 22 December 2014 (UTC)
  • To clarify, the output still works with both prefixes displaying a picture, so turning off the gadget without a replacement would be detrimental to all. Also, I'm not suggesting that we localise the actual namespace at Commons, simply that the string of text outputted by the gadget should include the localised prefix, and preferably a description that isn't simply the filename. ColonialGrid (talk) 18:25, 22 December 2014 (UTC)
I see the problem, but I think the solution is not quite what you requested. Let's say my preferred language is French. Even if that is so, the file prefix should be "Fichier" only if I am working on WP:FR. If I am working anywhere else, it should be in the appropriate local language, which is often not the User's selected language, as you requested above. — Preceding unsigned comment added by Jameslwoodward (talk • contribs) 15:03, 23 December 2014‎ (UTC)
  • Maybe so, but the chance of a user setting the language in Commons to Czech, and then editing in French Wiki would have to be minuscule compared to the number of users setting their language to Czech and editing in Czech Wiki (the situation that prompted this request). I also see no technical way of the system divining what language Wiki project you will be using the media in. Additionally, the issue of the gadget not retrieving the file description remains. However, would a dual lingual or choosable output appease your concerns? ColonialGrid (talk) 15:50, 23 December 2014 (UTC)
The English-language prefixes are the only ones guaranteed to work everywhere, so they should be the output of any such gadget. It is a million times more confusing if someone uses that gadget and it simply doesn't work at all (such as if someone has their language set to Czech, wants to add an image to frwiki, and gets a Czech prefix), than the minor inconvenience of an English-language word appearing in the wikicode (is anyone genuinely confused by that?). This gadget needs to be reliable, and the English-language prefix is simply the only reliable one. darkweasel94 16:57, 23 December 2014 (UTC)
I posted the question because it is really a problem for me. Mixing up different prefixes is confusing so every time I have to select the title just after the prefix and add the czech one or use the toolbar button. I would really appreciate if I could do this only with the very few non-czech wikipedia picture insertion I do. All the possible confusion could be solved by allowing this as an option in personal preferences. Matěj Orlický (talk) 09:27, 28 December 2014 (UTC)

Ban some of the automated Flickr uploading?[edit]

Huge numbers of images are being uploaded to Commons from Flickr. The automated uploads are being added without regard to suitability, whether they have a suitable description, and they are often being categorised incorrectly. In order to try and improve that standards of Commons I would like to see restrictions placed on some of the automated uploading. Is this something that the community would want to do? Alan Liefting (talk) 03:27, 27 December 2014 (UTC)

Script needed to hide all the latest contributions[edit]

I like to keep an eye on my edits to check for vandalism and to see if other editors agree with them. At present the Mediawiki software only lets you filter user contributions on having the latest revisions shown and does not give the inverse of it. Over at Wikipedia a script has been developed to will allow the user contribution list to only show entries that have had a subsequent edit. See w:User:Markhurd/hidetopcontrib.js. Can this useful script be developed for Commons? Alan Liefting (talk) 04:29, 27 December 2014 (UTC)

Improvement in speedy deletion procedure when a copyright violation is involved[edit]

Hi all, I've just have a discussion with a user that uploaded a couple of old photographs that were unfortunately copyrighted. He didn't have proper authorship information, but after some research I found out who the authors of the photographs were and concluded that, as they died 50 years ago, their photographs were not free yet. However, although the rationale I included in the {{copyvio}} template was self-explainatory, the uploaded didn't got that information in the automatic notification he received. Would it be possible to change the javascript handling the procedure so that the uploader receives the "reason" attached to the {{copyvio}} template also in the notification. Best regards --Discasto talk | contr. | es.wiki analysis 23:42, 27 December 2014 (UTC)

This would in theory be easy but in practise, we face into the issue that Commons is multilingual and the nominator and recipient of a deletion notification warning do not necessarily understand each other. And someone will have to re-write the templates to support a reason parameter. -- Rillke(q?) 04:21, 28 December 2014 (UTC)
These are ordinary templates, no scripting. The {{copyvio}} usage note suggests to use {{subst:copyvionote|1=Template:Copyvio}} ~~~~, if that isn't as you like it you could add a reason before the signature, or suggest an {{editprotected}} update of {{copyvionote}} on its talk page. It's substituted, if something goes wrong it won't break old notes. Or roll your own variant of "cvn", as Rillke said it must work for Arab, Chinese, Russian, etc. –Be..anyone (talk) 04:56, 28 December 2014 (UTC)