Commons:Village pump/Proposals

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

Shortcuts: COM:VP/P • COM:VPP

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; the latest archive is Commons:Village pump/Proposals/Archive/2024/03.

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?

 
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Allow WebP upload

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)[reply]

Support

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)[reply]

Oppose

Discussion

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)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Create PNG thumbnails of static GIF images

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.

Support

  1.  Support No brainer. --McZusatz (talk) 18:25, 14 July 2015 (UTC)[reply]
  2.  Support Indeed. The thumbnail of the GIF in it's file history shows this particularly well. Revent (talk) 19:49, 14 July 2015 (UTC)[reply]
  3.  Support A definite improvement. BD2412 T 20:12, 14 July 2015 (UTC)[reply]
  4.  Support I agree, seems like a great improvement for the users of our images. Reguyla (talk) 20:24, 14 July 2015 (UTC)[reply]
  5.  Support Seems like a straightforward improvement. — Julian H. 21:02, 14 July 2015 (UTC)[reply]
  6.  Support (please notify other projects about this proposal) --Steinsplitter (talk) 18:48, 16 July 2015 (UTC)[reply]
  7.  Support Makes sense. --Leyo 23:21, 22 July 2015 (UTC)[reply]
  8.  Support About time :D Absolutely supporting. -- Srđan 📣  05:13, 24 July 2015 (UTC)[reply]
  9.  Support Agreed. See also GNU vs GIF --Pkunk (talk) 05:28, 24 July 2015 (UTC)[reply]
  10.  Support Indeed.Mogoeilor (talk) 06:14, 24 July 2015 (UTC)[reply]
  11.  Support Hogne (talk) 06:18, 24 July 2015 (UTC)[reply]
  12.  Support Why not? And thanks for asking about! --Alex_brollo Talk|Contrib 06:21, 24 July 2015 (UTC)[reply]
  13.  Support Raymond 07:10, 24 July 2015 (UTC)[reply]
  14.  Support seems very logic to me, VIGNERON (talk) 07:22, 24 July 2015 (UTC)[reply]
  15.  Support Sounds reasonable. — Pinus 07:41, 24 July 2015 (UTC)[reply]
  16.  Subteno Simplaj sed efikaj! sısɐuuǝɔıʌ∀ (diskuto) 07:47, 24 July 2015 (UTC)[reply]
  17.  Support--Assar (talk) 07:58, 24 July 2015 (UTC)[reply]
  18.  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)[reply]
  19.  Support Vera (talk) 08:14, 24 July 2015 (UTC)[reply]
  20.  Support Yann (talk) 08:30, 24 July 2015 (UTC)[reply]
  21.  Support Thibaut120094 (talk) 08:36, 24 July 2015 (UTC)[reply]
  22.  Support Sémhur (talk) 08:42, 24 July 2015 (UTC)[reply]
  23.  Support Dsvyas (talk) 09:11, 24 July 2015 (UTC)[reply]
  24.  SupportTheDJ (talkcontribs) 09:43, 24 July 2015 (UTC)[reply]
  25.  Support Looks good to me. --Robbie SWE (talk) 09:44, 24 July 2015 (UTC)[reply]
  26.  Support --Tchoř (talk) 09:56, 24 July 2015 (UTC)[reply]
  27.  Support --Marceau (talk) 11:05, 24 July 2015 (UTC)[reply]
  28.  Support --Patrick87 (talk) 11:54, 24 July 2015 (UTC)[reply]
  29.  Support Syced (talk) 12:35, 24 July 2015 (UTC)[reply]
  30.  Support --Mmh (talk) 13:18, 24 July 2015 (UTC)[reply]
  31.  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)[reply]
  32.  Support PNG looks better. --Daniele Pugliesi (talk) 13:45, 24 July 2015 (UTC)[reply]
  33.  Support--Mavrikant (talk) 14:16, 24 July 2015 (UTC)[reply]
  34.  Support Don't see no reason why not. Amqui (talk) 16:32, 24 July 2015 (UTC)[reply]
  35.  Support Natuur12 (talk) 17:09, 24 July 2015 (UTC)[reply]
  36.  Support --Prog (talk) 17:41, 24 July 2015 (UTC)[reply]
  37.  Support Looks Good. --Ziad (talk) 19:25, 24 July 2015 (UTC)[reply]
  38.  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.  Support--Antigng (talk) 06:36, 25 July 2015 (UTC)[reply]
  40.  Support-- Balou46 (talk) 08:15, 25 July 2015 (UTC)[reply]
  41.  Support can't imagine reasons why not support. --Edgars2007 (talk) 09:14, 25 July 2015 (UTC)[reply]
  42.  Support. Strongly agree! 👦 Rachmat - t 10:03, 25 July 2015 (UTC)[reply]
  43.  Support Nyat (talk) 13:00, 25 July 2015 (UTC)[reply]
  44.  Support Finally!!! --Ernest-Mtl (talk) 13:02, 25 July 2015 (UTC)[reply]
  45.  Support ☆★Sanjeev Kumar (talk) 19:23, 25 July 2015 (UTC)[reply]
  46.  Support Palapa (talk) 20:32, 25 July 2015 (UTC)[reply]
  47.  Support Agree! NinjaStrikers «» 09:59, 27 July 2015 (UTC)[reply]
  48.  Support Abso-lutely. --wL <speak·creatively> 15:26, 27 July 2015 (UTC)[reply]
  49.  Strong support This should be happen when commons was born. --Liuxinyu970226 (talk) 22:59, 27 July 2015 (UTC)[reply]
  50.  Support --99of9 (talk) 04:54, 28 July 2015 (UTC)[reply]
  51.  Support--Dineshkumar Ponnusamy (talk) 09:24, 28 July 2015 (UTC)[reply]
  52.  SupportI support it as it looks it could help someone.--Juandev (talk) 09:29, 31 July 2015 (UTC)[reply]
  53.  Support --User:Armbrust (Local talk - en.Wikipedia talk) 13:53, 31 July 2015 (UTC)[reply]
  54.  Support the gain in quality worth the loss in bandwith --Xavier Combelle (talk) 17:01, 31 July 2015 (UTC)[reply]
  55.  Support Nonoxb (talk) 10:49, 6 August 2015 (UTC)[reply]
  56.  Support I'm a peng! guy -- Kays (T | C) 12:26, 26 August 2015 (UTC)[reply]
  57.  Support I seen several static GIF files rendered very badly. PNG thumbnail should not cause any technical problems. --Amitie 10g (talk) 21:20, 2 September 2015 (UTC)[reply]

Oppose

  1.  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)[reply]
    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)[reply]
    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)[reply]
  2.  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)[reply]
  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)[reply]
    "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)[reply]
    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)[reply]
  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).
     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)[reply]
  5.  Oppose GIFs should be abolished and converted to PNGs.--Kopiersperre (talk) 17:47, 28 July 2015 (UTC)[reply]
 Comment: For that reason exists User:GifTagger, but we shouldn't limit the file format choices. --Amitie 10g (talk) 22:45, 7 September 2015 (UTC)[reply]

Discussion

@Rillke: You mean a mass message to all VPs? --McZusatz (talk) 16:57, 16 July 2015 (UTC)[reply]
Yeah, I think this would be sufficient. -- Rillke(q?) 17:02, 16 July 2015 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
I doubt we can get both: Better quality and smaller file size. --McZusatz (talk) 22:12, 24 July 2015 (UTC)[reply]
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)[reply]
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)[reply]
Good catch! And maybe also a set of grayscale GIFs vs. coloured etc. --McZusatz (talk) 15:39, 25 July 2015 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]

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)[reply]

Category slideshow for category and its subcategories

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)[reply]

É uma ideia interessante. Há questões a considerar, com respeito à “profundidade” de subcategorias a expôr (uma questão tanto técnica como interfacial) e à ordem de exibição.
(corr. Google transl.) It’s an interesting idea. There are issues to consider with respect to the "depth" of subcategories to show (a matter both technical and of UI) and the display order.
-- Tuválkin 20:14, 24 August 2015 (UTC)[reply]
I would stick to what FastCCI (whose server backend returns machine-readable data) delivers. It should be not too difficult to implement. -- Rillke(q?) 14:53, 8 September 2015 (UTC)[reply]

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)[reply]

Achim I agree and so do a lot of other people. There has been several requests to fix this but its not very high on the developers list so it may be a while. Reguyla (talk) 21:31, 30 August 2015 (UTC)[reply]
Problem is that MW doesn't really understand the commons notion of a category redirect. If they used normal #redirect syntax, this would be trivial, but that's kind of broken for categories. Bawolff (talk) 09:38, 12 September 2015 (UTC)[reply]
Are there any reasons why a category page can't have both? #redirect for mediawiki (not only for this but for search functionality) and {{Category redirect}} for stuff like HotCat? sısɐuuǝɔıʌ∀ (diskuto) 09:34, 19 September 2015 (UTC)[reply]

Wikimedia Commons article traffic statistics for categories and for individual images

Translation of my proposal with translate.google.de:

In my view it would be very nice if there would be a "Wikimedia Commons article traffic statistics for categories and for individual images" (example: http://stats.grok.se/de/latest30/Allgemeine_Erkl%C3%A4rung_der_Menschenrechte)

Many greetings

--Molgreen (talk) 17:11, 16 August 2015 (UTC)[reply]

The German original of my proposal: Aus meiner Sicht wäre es sehr schön, wenn es für Kategorien und auch für einzelne Bilder eine Abrufstatistic wie in der Wikipedia geben würde (Beispiel: http://stats.grok.se/de/latest30/Allgemeine_Erkl%C3%A4rung_der_Menschenrechte) Viele Grüße

--Molgreen (talk) 17:11, 16 August 2015 (UTC)[reply]

It exists yet, for example: http://stats.grok.se/commons.m/201508/Hauptseite --Steinsplitter (talk) 17:14, 16 August 2015 (UTC)[reply]
Direct file views aren't included in stats.grok.se as far as I know, but they are available in a raw form - http://dumps.wikimedia.org/other/mediacounts/ Bawolff (talk) 07:02, 24 August 2015 (UTC)[reply]
Actually, direct file views are available (select the file on Commons in desktop view, click on the history page, and you can select the pageview stats). That said, most people want the indirect page views, which is the number of times the file has been viewed on Wikipedia and other projects (in all language versions). This is a bit like trying to collect page views for Wikipedia pages with lots of incoming redirects - you need to collect each instance of page view type separately. It can be done using the global usage tool, but is quite tedious. Jane023 (talk) 07:10, 24 August 2015 (UTC)[reply]
By direct view, I mean any view of the image (not the image description page). i.e. The number of hits the url at upload.wikimedia.org gets. That would include any time anyone viewed the image, no matter what page it is embedded in. The new mediacounts dump provides this, but nobody's made a pretty interface for it yet. Bawolff (talk) 16:03, 27 August 2015 (UTC)[reply]

SVG help button

Prototype

Hello!

I'm trying to improve usability of SVG contribution to Wikipedia. Since SVG is troublesome and buggy as I explained here, I wanted to improve this by adding a "SVG help" button to file description pages in case of SVG. Additionally it will only be visible if a loggedin user is visiting this page so it will have a small impact to the majority of visitors on commons. Since it is overall a simple task I've hacked a prototype of it: User:Menner/svg-button.js. It is a button with a pull down menu and four options to choose.

Can such a script be embedded on Commons by default? --Menner (talk) 16:47, 22 August 2015 (UTC)[reply]

My suggested prototype has evolved and I would call it ready for productive use. --Menner (talk) 07:14, 19 September 2015 (UTC)[reply]

Support

Oppose

Discussion

  • I think it should be implanted in MW directly instead of loading it via resource loader. But i think it will take ages until the wmf is implanting this in mw, so js would be a solution. The script does not support i18n. --Steinsplitter (talk) 09:54, 23 August 2015 (UTC)[reply]
Its too Wikimedia specific to be implemented in MediaWiki generically. Its possible that it could be implemented as a php extension that's only installed on wikimedia wikis (Or included in WikimediaMessages extension), but honestly, its probably a lot easier just to do in js. Bawolff (talk) 07:06, 24 August 2015 (UTC)[reply]
Obviously there is no general refusal of such a SVG button script. How can I start the vote/discussion to add this on commons as default by every user? --91.6.67.6 06:13, 31 August 2015 (UTC)[reply]
Hello? How will this proposal proceed? --Menner (talk) 19:14, 7 September 2015 (UTC)[reply]
@Menner: The script still does not support i18n. --Steinsplitter (talk) 10:03, 19 September 2015 (UTC)[reply]
@Steinsplitter: The help pages and the rest of the technical web are neither fully i18n. What kind of i18n do you request?--Menner (talk) 11:55, 19 September 2015 (UTC)[reply]
There should be a way to translate the makepLink. --Steinsplitter (talk) 11:59, 19 September 2015 (UTC)[reply]
i18n happens before calling makepLink and not everything going into it needs translations due to given Terms. -- Mennerk aka 91.63.190.207 14:03, 19 September 2015 (UTC)[reply]
But only the links are i18n. Not the text of the link? --Steinsplitter (talk) 14:14, 19 September 2015 (UTC)[reply]
When there is a link destination with translation then the text of the link is also i18n. -- Menner (talk) 07:20, 20 September 2015 (UTC)[reply]
Also I strongly oppose the current position of the button – already the crappy MediaViewer button is annoying the hell out of me. File description pages are for the file description. They should only contain specific information on the current file. Everything else is navigational and should therefore go into one of the navigation bars (possibly adding it to the #filetoc would beacceptable like the Stockphoto gadget does). Otherwise we're pushing down the information people want to actually see when visiting a file description page! --Patrick87 (talk) 11:11, 19 September 2015 (UTC)[reply]
The button is only visible to loggedin users and further only on file description for SVG files. I'm not pleased with #filetoc. The Add note and the Media Viewer can go to the no ones watching because it is useless area. They make every file descriptions popping around while loading. -- Menner (talk) 11:55, 19 September 2015 (UTC)[reply]
That's what I'm talking about! If every extension/gadget just carelessly adds buttons below the preview image sooner or later we have more buttons on our file description pages than we have file descriptions.
Since you basically seem to agree with my I'm afraid I have to ask though: Why treat your button differently than the others you dispise? If a button is useful or useless depends on the specific user. I (logged-in ) would not need the SVG help button – I know my way around SVGs – and I would think of it as "useless area" as you think of the MediaViewer/Add Note buttons as useless area. Other users certainly will profit from those buttons. Therefore we have to find a way to include them seamless into the navigational areas given to us instead of trying to judge by usefulness which is highly subective as pointed out above. --Patrick87 (talk) 12:41, 20 September 2015 (UTC)[reply]
I'm asking to treat the SVG button equal to other gadets. If previous things got that place I have the same rights. I even think the other (especially add note) are less important. Just look at grok.se how many people already find their way to the help page although it is "hidden" to the common uploader. It has nearly as much visits as Commons:Upload help according to grok.se which is very prominently placed at the Upload Wizard.
I could imagne to further limit the visibility of the SVG Button to the last uploader if there is support to gather last uploader.
-- Menner (talk) 16:57, 20 September 2015 (UTC)[reply]
"I'm asking to treat the SVG button equal to other gadets.": phab:T113177, MediaWiki talk:Gadget-ImageAnnotator.js#Position_of_the_.22Add_a_note.22_button. I for my part surely want to treat them equally . That other Extensions/Gadgets got their button there does not mean that was the right decision... --Patrick87 (talk) 17:27, 20 September 2015 (UTC)[reply]

Creation of PD template for Korea between 1910 and 1945

I found an old korean picture from the 1930s. Discussing the actual copyright status in COM:VPC, I propose to create a PD template for korean pictures (in my sandbox) taken/published between 1910 and 1945 (when Korea was occupied by Japan and before its splitting in the two current States), in similar way as {{PD-China}}.

For now, the tag shows texts indicating that the work is in the PD in the three countries, in Japan, the Republic of Korea and the Democratic People's Republic of Korea, and the three license tags {{PD-Japan-oldphoto}}, {{PD-South Korea}} and {{North Korea}}.

How can we improve this license tag? and more important, is actually viable to implement it? Please discuss, is very important to the several korean works unproperly licensed. --Amitie 10g (talk) 03:45, 26 August 2015 (UTC)[reply]

The tag should not say "taken" -- if photos were published elsewhere, that becomes the country of origin, not one of the Koreas. Also, I'm not sure I would include North Korea here. It appears they were not a part of any copyright treaty until 2003, and their law is from 2001. I have no idea what that law did to existing works... If they retroactively restored everything, then they have 50pma terms which cannot be guaranteed to have passed yet. There are no provisions in the law that I can see about what to do with existing uses of previously OK-to-use works, which you would normally expect if protection was being created for existing works. So, maybe it only applies to works published 2001 and later. It may be a law more for show than actual practice as well, which means it's anyone's guess what their protection for pre-2001 works is. Really, using the South Korea tag is probably enough for Commons purposes, since it was at least simultaneously published there, and that country probably has the shorter term anyways. Could add Japan I guess too.Carl Lindberg (talk) 07:15, 26 August 2015 (UTC)[reply]
Well, then I'll remove the DPRK, leaving just RoK and Japan, but I still considerig to keep the term taken, because is part of the {{PD-Japan-oldphoto}}; both term may coexist depending the date of making and publishing, IMHO. --Amitie 10g (talk) 09:14, 26 August 2015 (UTC)[reply]
No, Carl is correct, "taken" should not be in the summary at the top; this template is only appropriate for works that were published between 1910 and 1945 in occupied Korea. Works that were created between 1910 and 1945 in occupied Korea but published anytime or anywhere else should use the copyright template for where they were published (since the Berne convention defines the country of origin as where something was first published). For example, imagine a photo taken in 1940 in occupied Korea by a photographer who died in 2010 but first published in 2006 in the U.S. Such a photo could not use your proposed template as the photo's country of origin would be the U.S. and since the U.S. is pma+70, it's copyright would not expire until 2080. —RP88 (talk) 20:00, 26 August 2015 (UTC)[reply]
Whm, Carl is right, considering the overlapping the conditions of the both the Copyright Law of Japan and the RoK. Therefore, I added at the bottom the following centense
«This license applies only to works created in Korea and first published in that country. For works first published outside Korea, please use {{PD-South Korea}} only.»
Therefore, this template applies only for works first published (and created according to the Japan Copyright Law, but that term is somewhat questionable) in Korea and the author died after 70 years. How we can deal with the both Copyright Laws and the copyright status? --Amitie 10g (talk) 21:03, 26 August 2015 (UTC)[reply]
You should never use PD-South Korea for works first published outside Korea. Works first published in country X should use the appropriate rules for that country.--Prosfilaes (talk) 23:26, 26 August 2015 (UTC)[reply]
Whm you're right. Then, I changed to the country of the first publication instead. What about the prhase «applies only to works first published in Korea, and the author born in Korea and died after 70 years»? --Amitie 10g (talk) 04:38, 28 August 2015 (UTC)[reply]

Legal threats and blocking

Anyone object to this addition to the blocking policy? I self-reverted immediately after adding it; this was easier than attempting to explain the wording that I want and the location where I'd like to see it.

Rationale — I found such a threat and was curious how we handled them, since I routinely see en:wp using its legal threats policy but had never seen such a thing here. Not finding anything in the blocking policy, I ended up searching a while before I found the topic being addressed. There being lots of similarities between en:wp and us, addressing this difference seems helpful, and this difference being minor enough that it doesn't belong at Commons:For Wikipedians, I figured it would be helpful to include for future reference. Thoughts? Nyttend (talk) 00:18, 29 August 2015 (UTC)[reply]

I disagree with the outcome of the previous discussions – there was also Commons talk:Blocking policy/Archive 1#Legal threats – but I do agree that the prevailing position should be documented. LX (talk, contribs) 08:41, 29 August 2015 (UTC)[reply]
Hi, Actually "Legal threats" can be a reason for blocking. As the previous discussion mentioned, there are 2 different situations (copy-paste from Jim):
  • a threat of having a lawyer issue a takedown notice to Commons or of suing WMF to force the takedown of an image and
  • a threat of suing an individual editor or Admin for any reason.
The first is OK, the second is not. Regards, Yann (talk) 10:11, 29 August 2015 (UTC)[reply]
I disagree. The second can be okay as well. If someone is harassing or threatening me, I would consider suing. In this case I am the victim, why should I be victimized even more by being blocked? --Sebari (talk) 15:17, 29 August 2015 (UTC)[reply]
Will you then sue the person who blocked you? Legal threats have a huge chilling effect, and induce a lot of stress. If you can't resolve things within Commons, then you probably shouldn't be here.--Prosfilaes (talk) 22:24, 29 August 2015 (UTC)[reply]
If you think I should not sue someone who, to give an extreme example, issues death threats, you should most definitely not be here. --Sebari (talk) 08:44, 30 August 2015 (UTC)[reply]
I think anyone who issues death threats would be blocked as well ;-) If something warrants an actual lawsuit, go right ahead -- actually filing a real lawsuit against someone should not be grounds for blocking. But threatening it as an escalation of an argument in discussions here is a different matter. That has been the policy on en-wiki for quite some time. If someone is being abusive, there are other avenues to follow -- it should be pretty obvious for a situation which would legitimately be grounds for a lawsuit. I would agree though that DMCA threats are not the same and are OK -- that is copyright owner's right. In looking at the original proposal, that did seem to require a user to cease editing if they did file an actual (non-DMCA) lawsuit -- I don't think I'd support that. Barring discussion of the lawsuit itself maybe, but not all editing. Carl Lindberg (talk) 15:46, 30 August 2015 (UTC)[reply]
Can we offer any good example of someone who should be issuing a takedown notice instead of just putting it up for DR? The first is just as much a sign of problems as the second.--Prosfilaes (talk) 22:24, 29 August 2015 (UTC)[reply]
Hi, It would probably in case when a DR is closed as kept, and for other reasons than copyright. Regards, Yann (talk) 00:02, 30 August 2015 (UTC)[reply]
  •  Comment en:Wikipedia:No legal threats is very clear: "That users are involved in a legal dispute with each other, whether as a result of incidents on Wikipedia or elsewhere, is not a reason to block, so long as no legal threats are posted on Wikipedia." Taking legal actions against another person is one's basic right and we need not police it. But a threat like "I will sue you unless you stop" should not be posted on wiki. That's all. We need not bothered about take-down notices; it is a matter between WMF and the person. It is a common practice in OTRS too (if I remember well). Any mail with a threat tone will be forwarded to legal than replying by our volunteers. But we can prohibit posting taken-down threats like "I'll file a take-down unless you delete it" on wiki. (Sebari has the right to sue any; but should not make such threats on wiki.) Jee 02:27, 30 August 2015 (UTC)[reply]

Idea Portal for any Wikipedia user

translated with Google Translate:

The following links an implementation of a portal for ideas I like very much: simple, user-friendly and clear and with a voting option. I would like that very well for every Wikimedia user ... https://ideas.microfocus.com/mfi/novell-zcm

The German original of my proposal:

Der nachfolgende Link einer Umsetzung eines Portals für Ideen gefällt mir sehr gut: einfach, bedienerfreundlich und übersichtlich sowie mit einer Abstimmungs-Option. Das würde mir sehr gut für den jeden Wikimedia-Benutzer gefallen . . . https://ideas.microfocus.com/mfi/novell-zcm

Template for huge SVG files

I've created a template for huge SVG files (>10 MB), because the MediaWiki software is unable to render thumbnails for these files. This is intended specially for complex SVG like maps.

  • Could be this template useful, to be placed in the main Template: namespace?
  • Are these huge SVG (like this file) be ussable, if them can be replaced with hight-resolution raster version with lower filesize?

--Amitie 10g (talk) 22:41, 7 September 2015 (UTC)[reply]

I like your new template and I do think that it should be moved to Template namespace. These huge SVG are not unusable, just unusable by our current software. They should be scaled down and reuploded under new name, but the full version should be kept as the source. --Jarekt (talk) 13:26, 8 September 2015 (UTC)[reply]
OK, your opinion should be enough. I'll move the template. --Amitie 10g (talk) 16:19, 8 September 2015 (UTC)[reply]
btw, I expect the limit is 10 decimal MB, which is closer to 9.5 normal MB (or MiB if you prefer). Bawolff (talk) 09:39, 12 September 2015 (UTC)[reply]

Removing lightbox previews in UploadWizard

Hi, all!

As part of the changes we've been making to UploadWizard, we're updating the style of the dialogs used to display errors, display license previews, and so on. One dialog we're updating is the lightbox preview dialog, which you can summon by clicking on any of the small thumbnails in the deed or describe steps in the wizard.

My question to you is: Should we bother? Having a slightly bigger thumbnail of the image seems like a waste of time and code, and if we can axe this particular code path, it will simplify our lives in a few different ways. If nobody seems to actually use the lightbox, then we can safely delete it. If a few people do, then maybe we can learn about why and how, and possibly make the feature better.

Please let me know what you think here, or on IRC, or via e-mail if you prefer. Thanks! --MarkTraceur (talk) 18:40, 16 September 2015 (UTC)[reply]

I’d say you should not bother: Whoever is uploading anything is expected to have other ways to visualize the image(s), one Alt+Tab or Ctrl+Tab away. -- Tuválkin 00:06, 17 September 2015 (UTC)[reply]
I agree. I am using the upload wizard quite extensively (often uploading batches over 50 photos), and I have never needed a bigger preview. --Sebari (talk) 00:21, 17 September 2015 (UTC)[reply]
In fact I never even noticed its existence. :) Well, or maybe I noticed it few years ago and then stopped noticing. --Nemo 06:33, 18 September 2015 (UTC)[reply]
Me neither, but then again I rarely use the Wizard at all. If removing a bit of non-essential functionality makes it easier to get the UploadWizard work more reliably, then I'd say: Just axe it and don't look back. --El Grafo (talk) 13:19, 18 September 2015 (UTC)[reply]
User:Rillke/bigChunkedUpload.js is the only tool I use nowadays. Yesterday I'm a bit confused as the upload links are moved from "tools" menu to "edit source" as a drop-down menu. Jee 14:29, 18 September 2015 (UTC)[reply]

Available Download Resolutions

Hi, I'd like to discuss the different resolutions that are available to download on file pages. Currently, these seem to be the sizes where the long edge of the file is scaled to pixel counts of:

  • 320
  • 640
  • 800
  • 1024
  • 1280

As far as I can tell, this system was introduced around September 2011. In my eyes, there is a number of arguments for adding higher resolution options here, if the servers can handle them:

  1. The number of great files that we have that are larger than can reasonably be displayed in a browser for many people has grown significantly since then. If the browser refuses to display the full size, the next best option is the next smaller size that is offered - and that's 1280 pixels - not a size for enjoying any photo.
  2. We ask for the highest resolution photo that a photographer is willing to offer. The argument is that you can always scale down but not scale up. That's a weak argument if the user can only view a 1280 pixel thumbnail of an image or the full resolution version that often does not look very good if viewed with a 1:1 screen pixel ratio. Generally, I feel like the largest option should be an option that is actually useful for most situations. In a recent discussion about FP standards, there seemed to be a consensus that most files should be judged at around 6 megapixels, which is somewhere between QHD and UHD. For someone viewing an image on a full screen monitor, that allows for a bit of zoom to see some more detail. It is also roughly what you get in terms of actual sharpness with decent photography gear and technique, in most situations, even if your sensor gives you a much larger file. As a result, at this size and with some sharpening, most files look good or very good at 100%.
  3. Screens with resolutions of 1920 pixels or more had a less than 9% of total usage share in September 2011 according to statcounter.com data. This number has grown to over 17% globally (approximate numbers, I hope I didn't mess up the sums). So if people just want a wallpaper or a file that fills their screen for normal viewing, more of them are only left with downloading the full (sometimes huge) file nowadays. You can get a (good) 4k monitor for under $400 right now, so these are becoming common right now.
  4. Many users need to download vector graphics as pixel graphics because the software they use (MS Word is one example) can't deal with svg files. That's sad, but it's a reality that we have to deal with. Currently, there are additional (mostly overlapping) download resolutions for svg files, most notably adding a 2000 pixel option. Even though that's much better than 1280 pixels, it's still not enough to see a lot of detail in many files. Small countries on a world map are hard to find, just to give one example. It's also not ideal that a separate tool is necessary for that.
  5. Anyone can change to pixel size in the image retrieval url to a larger size. The server is happily serving me images at 8K and beyond. All that's missing are a few links for people who don't know that changing the resolution in the url is possible. If people don't need or use these, they don't put any load on the servers. If they do use them, I feel like that load is worth investing.

So to me, it feels like we should add a few more resolutions. The following ones seem reasonable to me:

  • 1366 (#1 worldwide)
  • 1440 (~#5 worldwide)
  • 1600 (~#6 worldwide)
  • 1920 (#2 worldwide)
  • 2560
  • 3840 or 4096

I would welcome a few opinions and thoughts on this, including good reasons why this would be a bad idea. Thanks, — Julian H. 11:06, 20 September 2015 (UTC)[reply]