Commons:Village pump/Proposals/Archive/2015/07

Removal of uploader information

There is a discussion regarding the removal of uploader information. See the discussion at the Village pump and the voting section. Offnfopt^(talk) 20:45, 21 July 2015 (UTC)

This section was archived on a request by: McZusatz (talk) 18:17, 24 July 2015 (UTC)

In addition to the field description (camera position), there are links to OpenStreetMap and Google Earth, OpenStreetMap works - Google Earth not

Translation by Google Translate:

In addition to the field description (camera position), there are links to OpenStreetMap and Google Earth

OpenStreetMap works - Google Earth not (tested with Internet Explorer, Fire Fox and Google Chrome)

See figure on the right

            **********************************************************************************

Here the German original: Neben dem Feld Beschreibung (Kamera Position) gibt es Links zu OpenStreetMap und Google Earth

OpenStreetMap funktioniert - Google Earth leider nicht (getestet mit Internet Explorer, Fire Fox und Google Chrome)

Siehe Abbildung rechts

--Molgreen (talk) 14:04, 24 July 2015 (UTC)

— Preceding unsigned comment added by Molgreen (talk • contribs) 14:02, 24 July 2015‎ (UTC)

It should work if you have Google Earth installed. The screenshot suggests that you don't have a registered default application for opening KML files, which in turn suggests that you don't have Google Earth installed. —LX (talk, contribs) 14:06, 24 July 2015 (UTC)

Thanks for the feedback: I'm sorry, I have Google Earth confused with Google Maps. --Molgreen (talk) 14:49, 24 July 2015 (UTC)

This section was archived on a request by: McZusatz (talk) 18:14, 24 July 2015 (UTC): I am assuming this is solved

Content creation Project: Card models and papercraft

https://commons.wikimedia.org/wiki/User:ShakespeareFan00/Card_Models

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

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")

Moved to Commons:Upload Wizard feedback/Archive/2015/07#"Assistant to upload files": Description Language (description) set of images by default to the current (login) language of the user (not always "English"). --McZusatz (talk) 18:16, 24 July 2015 (UTC)

Splitting Potd and Motd

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)

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

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:

Category-Name-Translation

|de=Windkraftanlage

|es=Aerogenerador

|fr=Éolienne

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

|nl=Windturbine

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)

Page logs

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)

 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.  Support in general. -- Rillke^(q?) 08:06, 19 July 2015 (UTC)
•  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)

• Steinsplitter, that sounds quite reasonable. I just want some way of presenting the log links in a convenient manner. You ask where the link should be presented: I was suggesting that we tack it on to MediaWiki:Filepage-nofile-link or MediaWiki:Moveddeleted-notice. Nyttend (talk) 21:09, 10 August 2015 (UTC)

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

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)

   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.  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).

    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.  Oppose GIFs should be abolished and converted to PNGs.--Kopiersperre (talk) 17:47, 28 July 2015 (UTC)

 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)

Discussion

• 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)

• is there a reason you are not implementing Graphs extension ? makes both obsolete ? Slowking4♡Farmbrough's revenge 02:53, 25 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)

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)

É 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)

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)