Commons:Village pump/Proposals

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

Shortcut: COM:VP/P· COM:VPP

  Welcome   Community portal   Help desk
Upload help
  Village pump
copyright • proposals
  Administrators' noticeboard
vandalism • user problems • blocks and protections
Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

Commons discussion pages (index)

Please note
  • One of Wikimedia Commons' basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?


Add Template:Commons upload tools or a link to Commons:Upload tools to Special:UploadWizard[edit]

Let's face it: In its current state the UploadWizard can be a major pita. We've been told that the developers are working on a major overhaul of the Wizard's back-end, but as far as I'm aware that may still take quite a while. We have several other methods for uploading content, but they are completely hidden from the casual user. Whenever you ask a frustrated user something like "have you tried turning it off and on again using Vicuna/Commonist instead" you get an answer similar to "I didn't even know something like this existed". In fact, I got that answer from rather experienced uploaders as well. I therefore propose to include Template:Commons upload tools at the bottom of the Special:UploadWizard starting page, or at the very least include a link to Commons:Upload tools (entitled alternative upload methods or something similar) right next to the "back to the old form" at the top of that page. --El Grafo (talk) 13:51, 17 June 2015 (UTC)

This is technically not yet possible: 1 --Steinsplitter (talk) 14:15, 17 June 2015 (UTC)
Well, I wasn't assuming that anyone here could actually do anything to that page. But the stuff above has taught me that it's better to have documented community consensus before you file a feature request. So here I am, asking for opinions. --El Grafo (talk) 14:42, 17 June 2015 (UTC) Or can our local admins edit the target of (mwe-upwiz-subhead-alt-upload)? Then we could point that to Commons:Upload tools and add the old form there under "Integrated tools" (the latter should be done anyway).
This seems to be pretty trivial and does not need consensus. Technically i can atm edit only the header but not the footer. Filed phabricator:T104009. --Steinsplitter (talk) 16:52, 26 June 2015 (UTC)

Thanks for doing this, I noticed and have been using it a lot. Jane023 (talk) 08:23, 24 July 2015 (UTC)

Allow WebP upload[edit]

WebP is an open file format to store images in a lossy or lossless way. It supports transparency in both the lossy and lossless mode while providing smaller file sizes when compared with JPEG or PNG compression (even animation like in GIF is possible). Despite the technical advance, WebP could never gain substantial support other than by it's creator (google).

Below is a separate subsection where opinions about enabling WebP upload to the WMF cluster should be discussed as well as subsections for voting about the WebP upload. --McZusatz (talk) 16:36, 28 June 2015 (UTC)


  • Symbol support vote.svg Support if and only if we get thumbnails in a format supported by Firefox and IE -- Rillke(q?) 19:50, 28 June 2015 (UTC)
Just for reference, the current implementation in MediaWiki is like SVG, in that when users upload a webp file, a PNG file is displayed to the user (I have no idea if in the long term we might do something more complex, but that's what is there now). Bawolff (talk) 20:42, 28 June 2015 (UTC)
  • Symbol support vote.svg Support (assuming Bawolff is correct, with the same thought as Rillke) ToBeFree (talk) 23:06, 28 June 2015 (UTC)
  • Symbol support vote.svg Support WebP has a lot going for it when it comes to usability in many scenarios. Image editor, image tool support seems to be fairly decent as well. Offnfopt(talk) 02:13, 29 June 2015 (UTC)
  • Symbol support vote.svg Support as long as we get thumbnails. --El Grafo (talk) 11:55, 29 June 2015 (UTC)
  • Symbol support vote.svg Support Can't think of a good reason not to assuming, as other supporters do, that thumbs work. Storkk (talk) 14:17, 30 June 2015 (UTC)
  • Symbol support vote.svg Support I see no harm in allowing the format to be used on commons even if its not widely used in industry. Reguyla (talk) 20:26, 14 July 2015 (UTC)
  • Symbol support vote.svg Support --Steinsplitter (talk) 18:49, 16 July 2015 (UTC)
  • Symbol support vote.svg Support to simplify the Web[AMP] upload documentation, otherwise I expect more from BPG. –Be..anyone (talk) 02:09, 17 July 2015 (UTC)
  • Symbol support vote.svg Support Indeed.Mogoeilor (talk) 06:15, 24 July 2015 (UTC)
  • Symbol support vote.svg Support Good reason to support... --Learnerktm (talk) 08:33, 24 July 2015 (UTC)
  • Symbol support vote.svg Support --Tchoř (talk) 09:58, 24 July 2015 (UTC)
  • Symbol support vote.svg Support. I agree with Reguyla. KiwiNeko14 (talk) 13:26, 24 July 2015 (UTC)
  • Symbol support vote.svg Support Agree.--Alexander Misel (talk) 02:35, 25 July 2015 (UTC)
  • Symbol support vote.svg Support Nyat (talk) 13:01, 25 July 2015 (UTC)


  • Symbol oppose vote.svg Oppose Where is anybody using this format? Or is it going to be used only for JPEG and TIFF files that have been converted to WebP? Smaller size is nice, but it's hardly a killer feature.--Prosfilaes (talk) 21:19, 29 June 2015 (UTC)
  • Symbol oppose vote.svg Oppose WebP is supported in very few browsers and picture editors. 37.97% of WMF browser traffic would get WebP images, the rest would get png thumbnails (calculated from stats:wikimedia/squids/SquidReportClients.htm and It is also very unlikely given this lack of support that WebP images would get uploaded.--Snaevar (talk) 13:03, 25 July 2015 (UTC)
  • Symbol oppose vote.svg Oppose Would be another image editing obstacle.--Kopiersperre (talk) 17:50, 28 July 2015 (UTC)


I believe in the technical superiority of WebP but many companies who enabled WebP had a response of bad user experience (e.g. facebook). Though, for all WebP files uploaded there would be thumbnails in the wider supported PNG format available for download. Still, user could normally not just download the full resolution and re-use it as is due to missing support (not to mention modify and upload an enhanced version). Furthermore, the Firefox web browser by Mozilla does not support WebP but Mozilla may take into account if WebP was enabled on the WMF cluster. (A comment in the bug tracker referring to it as the chicken-egg-problem) --McZusatz (talk) 16:36, 28 June 2015 (UTC)

COM:VPP may be a better place, if you want opinions of other language Wikimedians too. Jee 03:15, 29 June 2015 (UTC)

I agree with McZusatz, that it would be difficult for users who are offered a file in a format that their software doesn't support. There have been occasional complaints about Ogg formats I think, where there are good reasons for choosing the format. The problem could get worse over time, if WebP fails to take off and is abandoned by Google: it may be difficult to know what to do with these files in ten years. This would be offset on the other hand by a saving in storage space and network bandwidth, but since storage constraints are rarely if ever discussed on Commons, I have to assume it's not an issue. If WebP was widely supported, perhaps there'd be little reason not to convert existing files into that format and discard the originals, if no information was lost. --ghouston (talk) 04:03, 29 June 2015 (UTC)
There are already multiple file formats that users are able to download that they may not have software to support. Just with the other formats, we can point users in the right direction to the various software options available so they can take advantage of the media files. The issue at hand is not regarding converting existing files, we're basely talking about allowing WebP files to get uploaded in the first place. I think we need to worry about getting WebP allowed before we even worry about issues like converting existing media. WebP has a feature set that is not available in any of the other allowed formats. The source code for the WebP libraries and tools is open source, so the format will not just disappear. 10 years is a long time when it comes to computers, by that time no telling what technology or file formats will be in use, by that time we may end up having to convert most the media to a now unknown format. We should worry about if the WebP format is useful now and not about trying to predict the unknown future of technology. Offnfopt(talk) 04:56, 29 June 2015 (UTC)
Formats rarely just disappear, but I've certainly seen cases where it's hard to find a copy of a ten year old open source program and when it's found, you discover that it depends on long-obsolete libraries and can't be compiled without significant changes. --Prosfilaes (talk) 21:19, 29 June 2015 (UTC)
You're talking about a hypothetical issue that does not currently exist. That is not a reason to not use it. If everyone used that mentality when it came to Linux some 24 years ago, no one would have tried it and it may have not been further developed. WebP is still actively developed and it has been for 4 years. The latest commit to the repository was done yesterday. We already support WebM which is the sister format of WebP. WebP was developed from the compression used in WebM. If we are going to support WebM there is little reason to not support WebP since they are based on the same concepts. Offnfopt(talk) 23:38, 29 June 2015 (UTC)
WebM seems to have wider support than WebP, e.g., it's supported in Firefox. However it seems that Mozilla have decided not to support WebP in Firefox, on the grounds that they could get the same benefits by writing a better JPEG compressor. --ghouston (talk)
Mozilla have not decided against supporting WebP. I've read through both their tickets in bugzilla regarding WebP and the stance is they are undecided. They haven't made any concrete decision against WebP as it stands now. The JPEG encoder you're referencing "mozjpeg" is just that a JPEG encoder. Due to the format they are optimizing it only supports lossy compression, no lossless compression, WebP supports both. If you compare various JPEG and WebP files you'll notice less compression artifacts when using lossy compression compared to JPEG. The JPEG format being optimized doesn't support multi-level transparency (i.e. 8-bit alpha channel) or even any form of transparency because again the JPEG format they are optimizing doesn't support it, WebP does. WebP also supports muti-level transparency with both lossless and lossy compression. These features are also supported with animated WebP files. At this point in time we don't have support for any format with such a versatile feature set. We have nothing to lose by allowing WebP uploads. I think we should give WebP a chance.Offnfopt(talk) 01:44, 30 June 2015 (UTC)
You're talking about hypothetical support from Wikimedia, Mozilla and others, so I feel free to talk about hypothetical issues. A bunch of people had that attitude towards Linux 24 years ago, but see, people actually were in need of a free Unix kernel 24 years ago. I don't see the value in fancy new transparency for Commons, especially when nobody really supports it.--Prosfilaes (talk) 20:27, 30 June 2015 (UTC)
If you don't see value in the features of WebP then clearly you won't be using WebP. But just because you do not see the value of WebP does not mean you should limit others from taking advantage of those features. By allowing WebP will in no way negatively effect you. You will still be able to upload the same formats you have up till now. Offnfopt(talk) 21:24, 30 June 2015 (UTC)
It will mean that I can't usefully download highest-quality versions of works on Commons, either for personal use or to reupload to Commons. The list of formats is limited so that people don't have to worry that the file they download is in some random format they'll have trouble handling.--Prosfilaes (talk) 22:58, 30 June 2015 (UTC)
If you truly want to take full advantage of any of this media you should want to have the right software for the job. If you don't want to install additional software then you can use the PNG image that will be generated by the wikimedia site. We shouldn't hold back progress just because there are those that don't want to adapt to change. There are multiple file formats that we already support that require 3rd party software to take advantage of, this is no different. Offnfopt(talk) 23:53, 30 June 2015 (UTC)
Says the person writing in English, despite the fact there's been a century of better languages made to be international auxiliary languages. Says the person talking about a Unix kernel, despite the fact that Unix is a 45 year old standard that has seen many improvements. 20 years ago, I bought a program that converted 90 different image formats. It is simply not feasible to support all image formats, even if they are the shiny new thing, and dump the weight on the people who use Commons. We support odd video formats and sound formats for patent reasons, and DJVU and TIFF because that's what archives use.--Prosfilaes (talk) 01:31, 1 July 2015 (UTC)

Create PNG thumbnails of static GIF images[edit]

Static GIF files should have their thumbnails created in PNG. The advantages of PNG over GIF would be visible especially with GIF images using an alpha channel. (c.f. thumbnails on the side)

How a thumbnail of a selected GIF file looks like today.
How a PNG thumb of this GIF may look like after the software change.


  1. Symbol support vote.svg Support No brainer. --McZusatz (talk) 18:25, 14 July 2015 (UTC)
  2. Symbol support vote.svg Support Indeed. The thumbnail of the GIF in it's file history shows this particularly well. Revent (talk) 19:49, 14 July 2015 (UTC)
  3. Symbol support vote.svg Support A definite improvement. BD2412 T 20:12, 14 July 2015 (UTC)
  4. Symbol support vote.svg Support I agree, seems like a great improvement for the users of our images. Reguyla (talk) 20:24, 14 July 2015 (UTC)
  5. Symbol support vote.svg Support Seems like a straightforward improvement. — Julian H. 21:02, 14 July 2015 (UTC)
  6. Symbol support vote.svg Support (please notify other projects about this proposal) --Steinsplitter (talk) 18:48, 16 July 2015 (UTC)
  7. Symbol support vote.svg Support Makes sense. --Leyo 23:21, 22 July 2015 (UTC)
  8. Symbol support vote.svg Support About time :D Absolutely supporting. -- Srđan 📣  05:13, 24 July 2015 (UTC)
  9. Symbol support vote.svg Support Agreed. See also GNU vs GIF --Pkunk (talk) 05:28, 24 July 2015 (UTC)
  10. Symbol support vote.svg Support Indeed.Mogoeilor (talk) 06:14, 24 July 2015 (UTC)
  11. Symbol support vote.svg Support Hogne (talk) 06:18, 24 July 2015 (UTC)
  12. Symbol support vote.svg Support Why not? And thanks for asking about! --Alex_brollo Talk|Contrib 06:21, 24 July 2015 (UTC)
  13. Symbol support vote.svg Support Raymond 07:10, 24 July 2015 (UTC)
  14. Symbol support vote.svg Support seems very logic to me, VIGNERON (talk) 07:22, 24 July 2015 (UTC)
  15. Symbol support vote.svg Support Sounds reasonable. — Pinus 07:41, 24 July 2015 (UTC)
  16. Symbol support vote.svg Subteno Simplaj sed efikaj! sısɐuuǝɔıʌ∀ (diskuto) 07:47, 24 July 2015 (UTC)
  17. Symbol support vote.svg Support--Assar (talk) 07:58, 24 July 2015 (UTC)
  18. Symbol support vote.svg Support I'm too lazy to investigate why this wasn't the way things were done in the first place; they probably should have been. --Gutza (talk) 08:04, 24 July 2015 (UTC)
  19. Symbol support vote.svg Support Vera (talk) 08:14, 24 July 2015 (UTC)
  20. Symbol support vote.svg Support Yann (talk) 08:30, 24 July 2015 (UTC)
  21. Symbol support vote.svg Support Thibaut120094 (talk) 08:36, 24 July 2015 (UTC)
  22. Symbol support vote.svg Support Sémhur (talk) 08:42, 24 July 2015 (UTC)
  23. Symbol support vote.svg Support Dsvyas (talk) 09:11, 24 July 2015 (UTC)
  24. Symbol support vote.svg SupportTheDJ (talkcontribs) 09:43, 24 July 2015 (UTC)
  25. Symbol support vote.svg Support Looks good to me. --Robbie SWE (talk) 09:44, 24 July 2015 (UTC)
  26. Symbol support vote.svg Support --Tchoř (talk) 09:56, 24 July 2015 (UTC)
  27. Symbol support vote.svg Support --Marceau (talk) 11:05, 24 July 2015 (UTC)
  28. Symbol support vote.svg Support --Patrick87 (talk) 11:54, 24 July 2015 (UTC)
  29. Symbol support vote.svg Support Syced (talk) 12:35, 24 July 2015 (UTC)
  30. Symbol support vote.svg Support --Mmh (talk) 13:18, 24 July 2015 (UTC)
  31. Symbol support vote.svg Support. For me, PNG thumbnails and GIF thumbnails are just like day and night: the improvement brought by PNG thumbnails is immediately visible because it makes the preview instantly more recognizable. KiwiNeko14 (talk) 13:23, 24 July 2015 (UTC)
  32. Symbol support vote.svg Support PNG looks better. --Daniele Pugliesi (talk) 13:45, 24 July 2015 (UTC)
  33. Symbol support vote.svg Support--Mavrikant (talk) 14:16, 24 July 2015 (UTC)
  34. Symbol support vote.svg Support Don't see no reason why not. Amqui (talk) 16:32, 24 July 2015 (UTC)
  35. Symbol support vote.svg Support Natuur12 (talk) 17:09, 24 July 2015 (UTC)
  36. Symbol support vote.svg Support --Prog (talk) 17:41, 24 July 2015 (UTC)
  37. Symbol support vote.svg Support Looks Good. --Ziad (talk) 19:25, 24 July 2015 (UTC)
  38. Symbol support vote.svg Support — In the gif case, you sometimes feel the need to click on the image, just to make sure you didn't miss anything. --Wintereu 21:01, 24 July 2015 (UTC)
  39. Symbol support vote.svg Support--Antigng (talk) 06:36, 25 July 2015 (UTC)
  40. Symbol support vote.svg Support-- Balou46 (talk) 08:15, 25 July 2015 (UTC)
  41. Symbol support vote.svg Support can't imagine reasons why not support. --Edgars2007 (talk) 09:14, 25 July 2015 (UTC)
  42. Symbol support vote.svg Support. Strongly agree! 👦 Rachmat - t 10:03, 25 July 2015 (UTC)
  43. Symbol support vote.svg Support Nyat (talk) 13:00, 25 July 2015 (UTC)
  44. Symbol support vote.svg Support Finally!!! --Ernest-Mtl (talk) 13:02, 25 July 2015 (UTC)
  45. Symbol support vote.svg Support ☆★Sanjeev Kumar (talk) 19:23, 25 July 2015 (UTC)
  46. Symbol support vote.svg Support Palapa (talk) 20:32, 25 July 2015 (UTC)
  47. Symbol support vote.svg Support Agree! NinjaStrikers «» 09:59, 27 July 2015 (UTC)
  48. Symbol support vote.svg Support Abso-lutely. --wL <speak·creatively> 15:26, 27 July 2015 (UTC)
  49. Symbol strong support vote.svg Strong support This should be happen when commons was born. --Liuxinyu970226 (talk) 22:59, 27 July 2015 (UTC)
  50. Symbol support vote.svg Support --99of9 (talk) 04:54, 28 July 2015 (UTC)
  51. Symbol support vote.svg Support--Dineshkumar Ponnusamy (talk) 09:24, 28 July 2015 (UTC)
  52. Symbol support vote.svg SupportI support it as it looks it could help someone.--Juandev (talk) 09:29, 31 July 2015 (UTC)
  53. Symbol support vote.svg Support --User:Armbrust (Local talk - en.Wikipedia talk) 13:53, 31 July 2015 (UTC)
  54. Symbol support vote.svg Support the gain in quality worth the loss in bandwith --Xavier Combelle (talk) 17:01, 31 July 2015 (UTC)


  1. Symbol oppose vote.svg Oppose I can read the words in the given GIF-example, the words in the PNG-example appear smeared. That is due to my bad eyes. I might wear glasses, but do mid-to-end-40 men wear glasses volontariliy? Very opposed to this bad idea. --Matthiasb (talk) 09:24, 24 July 2015 (UTC)
    I have very bad sight (and, yes, I do wear very strong glasses and I am mid-to-end-40 man, too), and the PNG thumbnail is better readable for me, than the GIF thumbnail. --Mmh (talk) 13:12, 24 July 2015 (UTC)
    Hmm, we could actually make the text sharper. I believe we don't add sharpness to png images to avoid ringing/other artificats, which are more visible for the type of content normally in pngs. Bawolff (talk) 20:31, 24 July 2015 (UTC)
  2. Symbol oppose vote.svg Oppose if the new thumbnails are larger files than the original gifs - see discussion below. File size is a big deal on mobile and a bigger deal on mobile in the global south (slow networks and expensive data relative to local wage levels). Filceolaire (talk) 09:05, 25 July 2015 (UTC)
  3. Partially oppose -- The change to PNG thumbnails would be highly positive for GIFs with single-palette-color transparent background (not "alpha channel"!), and could slightly improve thumbnail quality for non-greyscale GIF images. However, for opaque grayscale GIFs, the PNG format has no technical improvement to offer over the GIF format, and in fact, in many cases with current algorithms, the PNG thumbnails would be larger in byte size than the GIF thumbnails, as is being discussed. Therefore I strongly oppose rendering static opaque grayscale GIFs with PNG resized thumbnails. For some past discussions, see Commons:Bots/Requests/GifTagger#Issues with greyscale and transparency, Template talk:BadGIF, etc... AnonMoos (talk) 09:40, 25 July 2015 (UTC)
    "However, for opaque grayscale GIFs, ... the PNG thumbnails would be larger in byte size than the GIF thumbnails, as is being discussed". Actually, the discussed file is larger due to the difference in transparency model. For opaque greyscale gif thumbnails, I would expect the file size to be less, as the compression algorithm in PNGs is generally supperior to GIFs. (However, this is something that should actually be tested). Bawolff (talk) 14:42, 25 July 2015 (UTC)
    I don't know what percentage would be larger under the current set-up, but historically PNG thumbnailing has been somewhat neglected, there have been some long-standing inefficiencies or problems, and not all changes have been for the better in all respects. For the latest anomaly, compare the 120px thumbnails of the file versions of File:Sefer raziel segulot.png (explanation on User talk:Cmdrjameson)... -- AnonMoos (talk) 02:33, 28 July 2015 (UTC)
  4. Nominal oppose The .png is blurry here, the .gif is not. Also for some files .svg would be the best solution. Rich Farmbrough, 00:38 27 July 2015 (GMT).
    Pictogram voting comment.svg Comment But at least logos lack of svg support, as phab:T86229 is unlikely to be resolved. --Liuxinyu970226 (talk) 22:56, 27 July 2015 (UTC)
  5. Symbol oppose vote.svg Oppose GIFs should be abolished and converted to PNGs.--Kopiersperre (talk) 17:47, 28 July 2015 (UTC)


  • This is nothing we can rule for other projects depending on us so I would suggest asking them beforehand to raise their concerns. -- Rillke(q?) 20:59, 14 July 2015 (UTC)
@Rillke: You mean a mass message to all VPs? --McZusatz (talk) 16:57, 16 July 2015 (UTC)
Yeah, I think this would be sufficient. -- Rillke(q?) 17:02, 16 July 2015 (UTC)

Just to be clear, you are proposing a software feature, not some kind of manual effort, right? --Tgr (talk) 05:21, 24 July 2015 (UTC)

Yes, the only manual effort is to change a line in the mediawiki software to serve PNG thumbnails instead of GIF thumbnails. --McZusatz (talk) 07:23, 24 July 2015 (UTC)

The description is a bit vague. I assume you propose that GIFs should be first converted to PNGs in their original size and than scaled down to create a thumbnail? If not, please correct my assumption. In any case, I encourage you to put the detailed description to the header. Also, was this consulted with developers to find out, that it is doable? (Links appreciated.) If it isn't doable then the entire voting probably doesn't have so much sense...
Danny B. 05:49, 24 July 2015 (UTC)

Creation of thumbnails is done by imagemagick and does not involve explicit conversion to PNG first. Instead, the PNG tumbnails is created from the GIF "on the fly". @Bawolff: Can you confirm? --McZusatz (talk) 07:23, 24 July 2015 (UTC)
Yes, that's correct. If this change was to be made, the file would be thumbnailed using image magick convert program, with the following command line invocation 'convert' '-background' 'white' '/var/www/w/git/../phase3/images/3/37/(R)-3-phenyl-cyclohanone.gif' '-thumbnail' '120x33!' '-set' 'comment' 'File source: http://localhost/w/git/index.php/File:(R)-3-phenyl-cyclohanone.gif' '-depth' '8' '-rotate' '-0' '/tmp/transform_495cd244452c-1.png'. I believe making the change would be fairly easy. However, it should be noted, that in this particular example, the png thumbnail (at least with this command, I'm sure the file size could be reduced significantly if hand optimized) is larger than the GIF thumbnail would be (and actually even larger than the original GIF file). This is presumably because in the GIF case the original image uses only 3 colours (and the gif thumbnail uses 41 colours), where the png thumbnail uses 355 colours (2 8-bit channels). Bawolff (talk) 12:31, 24 July 2015 (UTC)
@Bawolff: Increased size for thumbnails does not sound good at all, considering mobile users. Though, it should be noted that empirically (given the appropriate compression algorithm) PNG files are always smaller than GIF files with the same content. Do you think it is possible to pipe all PNG thumbnails through some PNG optimizer like zopfli (best open source PNG optimizer out there, to the best of my knowledge) or some less efficient but cheaper optimizer? --McZusatz (talk) 13:19, 24 July 2015 (UTC)
Well the thing is, that the content is not the same. All the extra shades of grey/shades of alpha that make the shrunk details more visible, take space. FWIW, pngcrush (which i just happened to have lying around), significantly reduced the file size, but... it was still bigger than the original gif. Lots of this is probably just that this specific example image is a bit of an edge case. As for PNG optimizers - if done immediately after file creation, there is a trade off between extra latency vs smaller size - a trade off that I think would probably be poor, especially for the slower optimizers. However if we did the compression after the fact, at times when nobody is requesting the thumbnail, it might make more sense. I suspect User:GDubuc_(WMF) would have thoughts on if png optimizers are a good idea. Bawolff (talk) 20:29, 24 July 2015 (UTC)
I doubt we can get both: Better quality and smaller file size. --McZusatz (talk) 22:12, 24 July 2015 (UTC)
Histogram showing the relative size distribution of compressed PNG thumbnails
Running over ~174 random ~120px thumbs gives that zopfli with default settings can compress most of them to 80% of their original size relatively fast.
for file in png_src/*;do echo $file;tools/zopfli-master/zopflipng $file out_png/$(basename $file);done
--McZusatz (talk) 22:12, 24 July 2015 (UTC)
Would it be possible for you to run this again and make the size of the compressed image relative to the size of the gif? Then we would see the size trade-off after conversion and compression. Jeblad (talk) 14:23, 25 July 2015 (UTC)
Good catch! And maybe also a set of grayscale GIFs vs. coloured etc. --McZusatz (talk) 15:39, 25 July 2015 (UTC)
i had no idea that tool offered such a high ratio of improvement. I agree we should def look into using it. Bawolff (talk) 16:13, 25 July 2015 (UTC)
I actually misread what you said to be an 80% reduction in size (not 80% of original size). /me gets slightly less excited, but still that's quite a saving. Bawolff (talk) 18:08, 26 July 2015 (UTC)

I support delivering PNGs by default. In my opinion GIF does not offer a single advantage over PNG (except animations). So actually usage of GIF should be avoided wherever possible anyway.
Note however, that the bad rendering quality of the example image is due to a limitation of the GIF file format: In GIF there's only one transparent color (there's no alpha channel as in PNG). Since the image has transparency the renderer tries to upscale it but is bound to this "1 bit transparency" which as a result looks very rugged. This could be easily resolved by removing the partial transparency in the image and replacing it by a plain white background (or rather converting the image to PNG). It's therefore not a real render issue but an issue of the file format itself. The comparison is therefore a bit "unfair" and we might even think about deprecating GIF to resolve the cause of the issue instead of concealing the symptoms. --Patrick87 (talk) 11:54, 24 July 2015 (UTC)

After a bit of high precision guesswork (!) it seems like we might end up with smaller files in mean after this change, but I would very much like to see actual numbers. Jeblad (talk) 01:05, 27 July 2015 (UTC)
A more elaborate report would take 1 or 2 days to create. My schedule allows me to create such earliest on Sunday; So everyone is welcome to beat me by that time. --McZusatz (talk) 14:46, 27 July 2015 (UTC)
  • Comment: Would it not be better if we moved towards converting such gifs into svgs? -- とある白い猫 ちぃ? 13:02, 24 July 2015 (UTC)
@とある白い猫: Conversion from gif to png is immediate (you need just a converter software) and the result in png is every time of higher quality. Instead to have an svg file with higher quality of gif you need to create it from zero and the result is better only at higher resolution, while for icons svg quality can be also worse of gif. For this reason, I disagree to "convert" gif to svg. Instead we can create an svg from a gif or png maintaining the original file whenever is necessary or we can suggest image authors to create svg instead of gif/png if they know how to do and if the image as to be shown larger (for example 200x200px or more). --Daniele Pugliesi (talk) 13:54, 24 July 2015 (UTC)
I am thinking about getting another mass message out there about the "converting the image to PNG" thing. --McZusatz (talk) 13:19, 24 July 2015 (UTC)
How does enabling an extension convert all existing raster images to Vega visualization grammar all of a suddden? --McZusatz (talk) 08:04, 25 July 2015 (UTC)
  • Comment: Why not just convert all static GIFs to PNG, which will result in PNG thumbs anyway? It's why we have {{BadGIF}} and {{Convert to PNG}}, the first of which notes, "Commons discourages the use of GIF files, except for animations." djr13 (talk) 12:28, 28 July 2015 (UTC)

Just as a side note: on systems with Retina displays the two thumbnails in the proposal above look exactly the same. --Dschwen (talk) 20:03, 25 July 2015 (UTC)

Page logs[edit]

File:Untitled.PNG was just fully protected at my request, since it's (not surprisingly) a vague and unhelpful name that's gotten uploaded repeatedly. However, when I visit it, I'm presented with what would be a confusing situation for someone who doesn't know what's going on: there's no "create" tab, and since protection isn't part of the deletion and move logs, nothing about protection is mentioned. It would be nice if the sidebar had a "Logs" link, but I don't see one; the only way I know to get the page's log is to go to Special:Log and enter the filename.

With this in mind, I'm proposing that we add a short link to one of the MW-space messages that appear on the page, either MediaWiki:Moveddeleted-notice or MediaWiki:Filepage-nofile-link. All we need is something like

View this page's logs

Putting it on Moveddeleted-notice would avoid the problem of people going to a never-touched image (e.g. because they had a typo in a filename) and seeing a log link there, but putting it on Filepage-nofile-link would allow the link to be presented on a title that has been protected although never edited; of course this is a rare situation, but it would apply to obviously bad filenames. Nyttend (talk) 21:16, 16 July 2015 (UTC)
Symbol support vote.svg Support. Linking to logs is very useful not just for inexperienced users to figure out what's going on, but also for experienced users. I have a function in my monobook.js to add a log link to all pages in the tools section of the sidebar, and I use it all the time for things like figuring out who uploaded a deleted file or if it's been previously uploaded. LX (talk, contribs) 06:20, 17 July 2015 (UTC)
  • Maybe using "all page's logs"? And instead of https:// please use Special:Log/. Where should this link be located exactly (example please)? --Steinsplitter (talk) 07:01, 19 July 2015 (UTC)
  • View this page's logs will possibly not explicitly address the issue brought up. This page is protected and therefore can't be created. View log. would be more explicit in this regard. Symbol support vote.svg Support in general. -- Rillke(q?) 08:06, 19 July 2015 (UTC)
  • Symbol support vote.svg Support --Yann (talk) 09:01, 23 July 2015 (UTC)
  • This page (logs) has been deleted. The deletion and move log for the page are provided below for reference. <<-- Something like this? --Steinsplitter (talk) 10:57, 23 July 2015 (UTC)

Content creation Project: Card models and papercraft[edit]

It needs a lot of work and input so posting an initial note here. ShakespeareFan00 (talk) 19:53, 19 July 2015 (UTC)

Proposed change to de-adminship policy[edit]

Please see Commons talk:Administrators/De-adminship#Proposed change to the minimum activity requirement. Green Giant (talk) 19:43, 21 July 2015 (UTC)

"Assistant to upload files": Description Language (description) set of images by default to the current (login) language of the user (not always "English")[edit]

Moved to Commons:Upload_Wizard_feedback#.22Assistant_to_upload_files.22:_Description_Language_.28description.29_set_of_images_by_default_to_the_current_.28login.29_language_of_the_user_.28not_always_.22English.22.29. --McZusatz (talk) 18:16, 24 July 2015 (UTC)

Splitting Potd and Motd[edit]

Currently many of the monthly Potd templates, for instance, Template:Potd/2015-07 contain both Pictures and Media of the Day. At the same time Template:Motd/2015-07 contains only media, but no pictures. Main page of Commons:Media of the day contains exclusively media and Commons:Picture of the day - exclusively pictures. Such inconsistency in Template:Potd/2015-07 is misleading and moreover, while it looks fine for English language, when you switch to other language - you see a lot of red links to non-existing Motd descriptions. I propose to clearly split Potd from Motd and in monthly Potd templates include only pictures. Then for projects (and languages) that like to have both, create templates titled Template:Potd and Motd/2015-07 (starting from 2009-06) and include them into Template:Potd and Motd/header instead of Template:Potd/2015-07-type templates. --Pavlo Chemist (talk) 14:16, 25 July 2015 (UTC)

Category slideshow for category and its subcategories[edit]

Fotomontage für Feature-Request: "Category Slideshow für Kategorie und deren Unterkategorien"

translated with Google Translate:

In my view it would be very nice if there would be next to the icon for the Main Category also an icon for Category slideshows category including its subcategories (see adjacent photo montage). If you want to look for example all pictures of Prenzlau, you would have to start 13(!) slideshow...

The original German text:

Aus meiner Sicht wäre es sehr schön, wenn es neben dem Icon für die Haupkategorie auch ein Icon für die Category Slideshow der Kategorie einschließlich deren Unterkategorien geben würde (siehe nebenstehende Fotomontage). Will man sich zu Beispiel alle Bilder zu Prenzlau ansehen, müsste man 13(!) Slideshows starten ...

--Molgreen (talk) 15:14, 30 July 2015 (UTC)

Names of the categories in English and in the language of the current user or in the main language of the browser[edit]


translated with Google Translate:

It is very good that at Commons and Wikipedia in general is the English as their main language or base language. At the same time I would hope very much that the names of the categories in Wikimedia Commons would also be displayed in the language of the current user or in the language of the main language of the browser. (This is of course only insofar as the translation is filed. If the technical conditions are met, the would Populate yes.)

It would be important to me that you can look for the translated names and the translated name and can be used in the assignment of pictures to categories.

As I imagine it, I have shown in the adjacent photo montage for the "Wind turbines" category.

Many Greetings

The original German text:

Namen der Kategorien in Englisch und in der Sprache des angemeldeten Benutzers beziehungsweise in der Hauptsprache des Browsers

Es ist sehr gut, dass bei Commons und Wikipedia allgemein die Englisch als Hauptsprache beziehungsweise Basissprache ist.

Gleichzeitig würde ich mir sehr wünschen, dass die Namen der Kategorien in WIKIMEDIA COMMONS auch in der Sprache des angemeldeten Benutzers oder in der Sprache der Hauptsprache des Browsers angezeigt werden würden. (Das geht natürlich nur soweit die entsprechende Übersetzung hinterlegt wird. Wenn die technischen Voraussetzungen gegeben sind, ließe sich das ja einpflegen.)

Wichtig wäre mir, dass man nach den übersetzten Namen suchen kann und die übersetzten Namen und bei der Zuordnung von Bildern zu Kategorien verwenden kann.

Wie ich es mir vorstelle, habe ich in der nebenstehende Fotomontage für die Kategorie „Wind turbines“ dargestellt.

Viele Grüße

--Molgreen (talk) 15:53, 30 July 2015 (UTC)

There is {{other language}} (and the non-adaptive {{translation table}}) which can already be used to provide category name translations, implementing your proposal would result in a huge categorisation mess since there are no exact translations for many terms and even if there were, Commons would simply lack the human resources or external sources for translations of the millions of categories into the hundreds of languages MediaWiki supports.    FDMS  4    19:25, 30 July 2015 (UTC)
Hello FDMS,

thank you very much for your feedback. This is a shame, in my view. I've often found categories in German, to the same content in parallel existed in English and really should be a single. I also realize that may not be all categories translated into all languages. (Also because of translation problems.) ({{translation table}} translation table is a great way that I use already) My idea would be that one category is for delimiting identifiers created in English and then translations could be added: For Example:





|mk=Ветерна турбина


in German:

Hallo FDMS,

herzlichen Dank für Deine Rückmeldung. Das ist aus meiner Sicht sehr schade. Ich habe schon oft Kategorien in Deutsch gefunden, die parallel zu inhaltgleichen in Englisch existierten und eigentlich eine einzige sein sollten. Mir ist auch klar, dass nicht alle Kategorien in allen Sprachen übersetzt werden können. (Auch wegen der Übersetzungsprobleme.) {{translation table}} ist eine gute Möglichkeit, die ich schon nutze. Meine Vorstellung wäre, dass eine Kategorie standradmäßig in Englisch angelegt wird und dann Übersetzungen hinzugefügt werden könnten:

--Molgreen (talk) 06:13, 31 July 2015 (UTC)

Translated with Google Translate:

Three other arguments, I would add:
  • The integration of translation could prevent that categories are repeatedly created in different languages.
  • If we want that can use "any" Wikimedia Commons, there should be an automatic translation feature. Not everyone can speak English.
  • The "Universal Declaration of Human Rights" is an example for me that translations can work well: Universal Declaration of Human Rights and Allgemeine Erklärung der Menschenrechte

Subsequently, the German original:

Drei weitere Argumente möchte ich noch hinzufügen:
  • Durch die Einbindung von Übersetzung ließe sich verhindern, dass Kategorien mehrfach in verschiedenen Sprachen angelegt werden.
  • Wenn wir wollen, dass „jeder“ Wikimedia Commons nutzen kann, sollte es eine automatische Übersetzungsfunktion geben. Nicht jeder kann Englisch.
  • Die „Allgemeine Erklärung der Menschenrechte“ ist für mich ein Beispiel, dass Übersetzungen gut funktionieren können: Universal Declaration of Human Rights and Allgemeine Erklärung der Menschenrechte

--Molgreen (talk) 05:18, 2 August 2015 (UTC)


The page Special:UnusedCategories isn't very useful the way it is because category redirects are there listed too which are of course unused by this point of view. Therefore imo it would be better if this page didn't contain category redirects. --Achim (talk) 10:10, 1 August 2015 (UTC)