Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Multimedia

< Community Wishlist Survey 2016
Multimedia
23 proposals, 182 contributors, 358 support votes



Default alt text in image file

  • Problem: Alt text is part of our accessibility policy, but is rarely made available.
  • Who would benefit: People with impaired vision, especially those who use screen readers.
  • Proposed solution: Currently alt text is supposed to be added to the image link for each use of the image. I suggest allowing an image file to contain an alt text field that would be the default if there were no alt text in the image link. We might then have an activity for creating alt text images that are used in high profile and multiple articles. There is even a possibility of using machine learning tools to come up with alt text for images. Worth a try.

Community discussion

  • This would be quite a feat but it would also be quite useful for those who can't view an image, I like this idea! SamanthaNguyen (talk) 03:55, 21 November 2016 (UTC)[reply]
  • Better than the file name which is what we do now. However, only 20% (832,142/4,068,175) of images are reused, many seem to be portraits, some of those are "flavor" image like adding a NYC skyline to List of New Yorkers. I've prototyped a copy alt text tool without much success (too few alt texts and different image usages). I'm looking into machine generation, see #Computer vision above. Full disclosure: I have a WMF grant to improve alt text. Dispenser (talk) 01:16, 23 November 2016 (UTC)[reply]
  • What text should be used as ALT text of the image in Wikipedia by default, when the ALT tag is not fulfilled? File name is too short for such purpose. The description from the "Information template" would fulfill such purpose.

{{Information |description = {{de|Wasserschloss (von der Poggenmühlenbrücke aus gesehen) bei Nacht, Speicherstadt, [[:de:Hamburg|Hamburg]], Deutschland}} {{en|Wasserschloss (view from the Poggenmühlenbrücke) in the night, Speicherstadt, [[:en:Hamburg|Hamburg]], Germany}} and so on... }}

When is the description available on Commons in corresponding language, then it can be added by Bot to existing Wikipedia articles.

Ideally users should be adding ALT text manually during the editing of the article, directly when they are adding the image to article together with image caption. Therefore the visual editor should have the field ALT text. The visual editor is an advantage, because the visual editor should preload the alt text automatically.

If the visual editor is turned off (Special:Preferences#mw-prefsection-editing "Temporarily disable the visual editor while it is in beta.") then alt tags should be added automatically somehow. For example when user added image, he shows the preview, then the preview should automatically add ALT tag at the end of the image like this:

[[File:Image.png|thumb|caption]] -> [[File:Image.png|thumb|caption|alt=text from description]]

When there is available description of the image at Commons in corresponding language, then it can be added AUTOMATICALLY during the user's edit. User will see during the preview, that the system added ALT tags automatically. Then user can decide to save it with such ALT tags, or the user can decide to add/modify them. When there is no available description, then the system should add the same alt tag as the caption. (Yes, I know, captions should not be ideally used in ALT text, but 1) such alt texts are better than actual situation that shows the image name and 2) I presume, that modification of caption into proper alt text is easier than to write completely new alt text. At least for me - for the user who knows how to write alt tags - it would be useful.)

[[File:Image.png|thumb|caption]] -> [[File:Image.png|thumb|caption|alt=caption]]

If there is even no caption (it is related to the way, how images without caption are used on Wikipedia), then the empty ALT tag should be added. Empty alt tag is better than nothing, because it shows to the editor, that there is something missing and users will add it later.

[[File:Image.png|thumb]] -> [[File:Image.png|thumb|alt=]]

I think, that computer vision can not resolve it for now. Consider, that computer vision is unable to add the most simple alt text for portrait in infoboxes. It can not add for example alt text like this yet: "1921 black-and-white photo of Albert Einstein", because computer vision will not recognize the type of the image yet (painting/drawing/photo/black-and-white photo). Computer vision will be improving and maybe it could do much work in such special cases such as infoboxes, but the responsibility will be on users anyway.

This describes the solution for standard thumb images; alt tags for images inside templates (such as infoboxes, taxoboxes, etc.) will require special approach. This is the best solution what we have now and if we do not want to contradict our own policies, then we must apply such solution. If are missing ALT tags against the Wikimedia's policy, then we should alter the wiki software in the way, that will force adding them. --Snek01 (talk) 15:36, 23 November 2016 (UTC)[reply]

I just reread w:Wikipedia:Alternative text for images and it seems somewhat disconnected from reality. It's idea of alt text is not very different from what belongs in a proper caption. Why add alt text then instead of improving captions? It also says all images should have some alt text when hardly any do. Copying the image description has the problem of what happens when the image description is updated. It's bad database design to have the same data in different states in different places. Having the ALT txt default to the image description when there is a matching language would be better. Right now it defaults to the file name, which is often unhelpful. My thought for an AI system would be to describe the image, e.g. instead of "1921 black-and-white photo of Albert Einstein" one might have "Man with dark hair and mustache standing in front of a blackboard." That might be within the aspirational range of AI image processing and might give people who can't see images some idea of what is being shown. Another possibility might be a tool that lists the alt-free images in articles by article popularity. That would facilitate an effort to add ALT text. A proper next step would be to get input from people who actually use screen readers as to what would be most helpful.--ArnoldReinhold (talk) 20:22, 27 November 2016 (UTC)[reply]

Voting – Default alt text in image file

  1.   Support--Shizhao (talk) 03:05, 28 November 2016 (UTC)[reply]
  2.   Support--Aracali (talk) 14:59, 28 November 2016 (UTC)[reply]
  3.   Support --Snek01 (talk) 15:19, 29 November 2016 (UTC)[reply]
  4.   Support --Matthiaspaul (talk) 00:59, 30 November 2016 (UTC)[reply]
  5.   Support — Pajz (talk) 12:20, 1 December 2016 (UTC)[reply]
  6.   Support This should be a number one priority--to export alt text across projects with the file itself. —Justin (koavf)❤T☮C☺M☯ 03:55, 2 December 2016 (UTC)[reply]
  7.   Support SamanthaNguyen (talk) 01:30, 3 December 2016 (UTC)[reply]
  8.   Support Strong support! --β16 - (talk) 11:17, 5 December 2016 (UTC)[reply]
  9.   Support--Praveen:talk 13:04, 5 December 2016 (UTC)[reply]
  10.   Support A very simple idea, and it's important for accessibility. --Tryptofish (talk) 00:10, 6 December 2016 (UTC)[reply]
  11.   Support Andyrom75 (talk) 09:15, 6 December 2016 (UTC)[reply]
  12.   Support--Ranjithsiji (talk) 11:08, 6 December 2016 (UTC)[reply]
  13.   Support--Ανώνυμος Βικιπαιδιστής (talk) 21:14, 6 December 2016 (UTC)[reply]
  14.   Support--EftichiaKosma (talk) 7:51, 7 December 2016 (UTC)
  15.   Support An idea long past its time in coming. Daniel Case (talk) 05:33, 8 December 2016 (UTC)[reply]
  16.   Support Miniapolis 20:19, 9 December 2016 (UTC)[reply]
  17.   Support 4nn1l2 (talk) 23:45, 10 December 2016 (UTC)[reply]
  18.   Support Potential great accessibility boon.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:17, 11 December 2016 (UTC)[reply]
  19.   Support Parzi (talk) 21:39, 11 December 2016 (UTC)[reply]
  20.   Support, let's make Wikimedia Commons more collaborative — NickK (talk) 13:48, 12 December 2016 (UTC)[reply]
  21.   Support --Yann (talk) 23:13, 12 December 2016 (UTC)[reply]

Also display images from subcategories

  • Problem: Sometimes I look in a given category for a picture that would illustrate my article. Unfortunately, many categories have only a few pictures in the main category, as most of the images are hidden in the numerous subcategories. Clicking on several subcategories to find 3 or 4 images is a waste of time.
    Czasami szukam w danej kategorii obrazka, który dobrze ilustrowałby mój artykuł. Niestety, wiele kategorii ma niewiele obrazków w kategorii głównej, większość obrazków jest ukryta w niezbyt licznych podkategoriach. Klikanie w kilkanaście podkategorii, żeby obejrzeć 3 czy 4 obrazki to strata czasu.
  • Who would benefit: Commons
  • Proposed solution: A great solution would be a button like "Also display images from subcategories"
    Wspaniałym rozwiązaniem byłby przycisk "Wyświetl także obrazy z podkategorii"
Comment: This could also be useful in other places, f.e. to search/view into deep category trees. (Sidenote: I once implemented this basic idea in a forum software to include threads from sub-forums into higher level thread lists, so you could "narrow" down the included threads the deeper you'd go in the sub-forum hierarchy - similar to what happens f.e. on ebay etc. I called this concept "flat views". Of course, it should be optional, so the user can switch between the normal hierarchical view and the flat view by the press of a button. --Matthiaspaul (talk) 00:56, 30 November 2016 (UTC)).[reply]
  • Phabricator tickets:

Community discussion

I have fixed the translation slightly; additional help at the "problem" section would be useful. עוד מישהו Od Mishehu 12:24, 10 November 2016 (UTC)[reply]

Voting – Also display images from subcategories

  1.   Support Currently it is extremely difficult for non-experienced users to find suitable freely-licensed images on Commons for external use where there are many sub-categories all of which might contain something useful. MichaelMaggs (talk) 20:16, 28 November 2016 (UTC)[reply]
  2.   Support --Jan.Kamenicek (talk) 00:29, 30 November 2016 (UTC)[reply]
  3.   Support --Matthiaspaul (talk) 00:56, 30 November 2016 (UTC)[reply]
    Comment --Please read the discussion, the feature already exists! Its existence just needs to be publicized better.--ArnoldReinhold (talk) 17:01, 30 November 2016 (UTC)[reply]
  4.   Support Libcub (talk) 02:51, 2 December 2016 (UTC)[reply]
  5.   Support Railwayfan2005 (talk) 23:04, 3 December 2016 (UTC)[reply]
  6.   Support -<(kmk)>- (talk) 17:10, 5 December 2016 (UTC) per MichaelMaggs. If the "Good images" button can serve the purpose, then please redesign the UI to something more obvious.[reply]
  7.   Support --Almondega (talk) 11:18, 6 December 2016 (UTC)[reply]
  8.   Support--EftichiaKosma (talk) 7:51, 7 December 2016 (UTC)
  9.   Support--Alexmar983 (talk) 08:59, 8 December 2016 (UTC)[reply]
  10.   Strong support-- --Ttzavaras (talk) 19:34, 9 December 2016 (UTC)[reply]
  11.   Support --NaBUru38 (talk)
  12.   Support. I would particularly like this feature when a category is split into subcategories like John Doe in 2010: if I am looking for a particular type of image (e.g. a portrait facing left) I don't really care whether it was taken in 2010 or in 2016 — NickK (talk) 13:50, 12 December 2016 (UTC)[reply]

Imagemap highlighting

  • Problem:
    • Contributing in Wikipedia is not easy for primary education or all people
    • Reading article text or viewing a static image does not give quick visual information and is not interactive.
  • Who would benefit:
    • Desktop users, (tablet and mobile users on the next release of MS and Apple's proximity sensors)
    • Primary education / special people education
    • Anatomy, archaeology, physical sciences, almost any kind of articles would benefit as images become interactive easily.
  • More comments:
    • Imagemap highlighting needs precise image mapping in polygons (we do not enable it in draft imagemaps).
    • Ideally, image mapping tools should be part of Wiki tools like VisualEditor.
  • Phabricator tickets:

Community discussion

  • @ManosHacker: I've moved this here, from the Miscellaneous page. Thanks! Quiddity (WMF) (talk) 00:49, 22 November 2016 (UTC)[reply]
  • Wasn't the editing/multimedia team working on file annotations to replace image annotator ? Seems like there is community interest to bring that further then. —TheDJ (talk • contribs) 15:28, 23 November 2016 (UTC)[reply]
    • Yes, and this kind of feedback and parallel progress is great. Everyone interested should read through mw:Help:Extension:FileAnnotations and also mw:Extension:FileAnnotations/Design, and click through to Commonswiki for the linked example images, and then comment on the discussion page with your ideas. Each of the extensions has unique strengths (FileAnnotations is more extensible for adding text, images, and other content to the interaction (allowing for more structured data, e.g. using Wikidata links to tag a "skull" in a skeleton diagram, making it easier for all projects to re-use); whereas ImageMap only supports links. ImageMap supports complex polygons; FileAnnotations does not yet), and they will probably coexist for a while. There is still a lot of work to do, planning and discussing feature-sets, use-cases, and potential directions. This proposal could be good for getting a list of interested people, for that work. Quiddity (WMF) (talk) 19:56, 24 November 2016 (UTC)[reply]
      • In additon to polygons: in Imagemap Highlighting only connected elements are revealed, on hover, (grouping), and these connections give information.
      • It would be great to support more than links in imagemap, but after a delay, as popping up would be annoying for imagemap highlighting functionality.
      • Imagemap data is article based, not image based.
--ManosHacker (talk) 07:08, 26 November 2016 (UTC)[reply]

Voting – Imagemap highlighting

  1.   Support --FocalPoint (talk) 06:28, 3 December 2016 (UTC)[reply]
  2.   Support This could prove an invaluable tool both for Wikitherapy and for my school projects. Kudos to the developers :) --Saintfevrier (talk) 09:12, 5 December 2016 (UTC)[reply]
  3.   Support --MenelaosGkikas (talk) 00:22, 6 December 2016 (UTC)[reply]
  4.   Support Great tool for education! --Ενσυναίσθηση (talk) 22:47, 5 December 2016 (UTC)[reply]
  5.   Support --Giorgos ab1234 (talk) 08:10, 6 December 2016 (UTC)[reply]
  6.   Support --V-astro, 9:20, 6 December 2016 (UTC)
  7.   Support This is a great educational tool! --Aristo Class (talk) 12:32, 6 December 2016 (UTC)[reply]
  8.   Support --Ανώνυμος Βικιπαιδιστής (talk) 21:15, 6 December 2016 (UTC)[reply]
  9.   Support--EftichiaKosma (talk) 7:51, 7 December 2016 (UTC)
  10.   Support Dafniotis (talk) 07:44, 8 December 2016 (UTC)[reply]
  11.   Support P.aimel'écriture (talk) 13:00, 8 December 2016 (UTC)P.ainel'écriture[reply]
  12.   Support--PapaJohnWp (talk) 18:46, 9 December 2016 (UTC)[reply]
  13.   Support-- Very helpful educational tool! --Ttzavaras (talk) 19:27, 9 December 2016 (UTC)[reply]
  14.   Support --NaBUru38 (talk)
  15.   Support -- Anna Diderot (talk) 17:41, 11 December 2016 (UTC)[reply]

Display rectangular part of the image as parameter of File and compatible with ImageNote

  • Problem: There are tens of thousands composed images, plates (and other similar images). There is need usually only certain part of such image to be viewed in encyclopedic article at Wikipedia.

Compare the following images:

  •  
  •  
  •  
    image from the museum
  •  
    cropped image of Rivomarginella electrum
  •  
  •  
  •  
  •  

Creating such cropped images is very time consuming. It is necessary to download the image, crop it, create new descriptive name, upload the image, add proper description, add categorization, add links to source image and add link from source file to derived file. (It is also useful to improve the quality of the images, such as remove background, remove captions, or rotate the image.)

It would be useful if it would be possible to view the certain rectangular area of the larger image from Commons on the Wikipedia directly without needing to upload the cropped image.

  • Who would benefit: Editors will save time. Readers will have proper encyclopedic images in more articles.
  • Proposed solution: Use ImageNote template commons:Template:ImageNote as a parameter of File to show rectangular part of the image.
  1. I will go to the image page at Commons. For example https://commons.wikimedia.org/wiki/File:Malacologists_1914.png
  2. I will add a note to the image with "Add a note button".
  3. I will go to the Wikipedia page. For example https://en.wikipedia.org/wiki/Truman_H._Aldrich
  4. I will edit the Wikipedia page and I will add the image

[[File:Malacologists_1914.png|thumb|Truman H. Aldrich|{{ImageNote|id=3|x=901|y=383|w=168|h=235|dimx=1782|dimy=1364|style=2}}]]

This is just an example how it should work. We can benefit from the fact, that using of the ImageNote is standard on the Commons already.

  • More comments:

Some of such images (plates) are not needed at Commons at all, especially if they are at Internet Archive. But some of them are at commons only and are not accessible anywhere else.

The cropped image of Rivomarginella electrum is not very high quality and it will be replaced immediately when probably any other image of the same species will be uploaded to Commons. Then the cropped image will not be needed at all (and could be deleted). But the deletion process is sometimes much more consuming than uploading images. Consider that there are over 100.000 of such images of molluscs only at Commons. It is not possible to do it manually (we have not such many editors with such much time), especially when we known, that at least some of such cropped images will be certainly replaced and will became unusable.

Many images cropped from plates usually need some editing. In such cases will be this solution only temporal. This will help to save time to editors and meantime to show at least some image to readers.

But we can use it for plates forever for such plates, that does not need alteration.

This example is about molluscs only. But the usage of the solution is universal:

  •  
  •  
  •  
    There are number of such details made from paintings. Usually without alterations.
  •  
  •  
    Another practical application is the Wikipedia Main Page. There are usually more or less square details. There are usually larger version in Wikipedia articles, while on the Main Page there must be the same image informative and easily recognizable in 100x100 pixels.
  • Phabricator tickets:

Community discussion

Thanks. That is a step forward. CSS_image_crop uses the same idea; it is "for linking to full images when a slight crop is preferred in an article". Unfortunately I can not use it for now. It is not standard and it is extremely difficult to use.
  1. CSS_image_crop does not allow generate standard thumb size. We do not need fixed size. We need thumb size. Thumb size is a standard. We do not only need to view the selected area, but we need to view it in a standard thumb size. Thumb size is absolutely necessary. Suggestion: make CSS_image_crop template compatible with standard thumb image size.
  2. How do you get informations for parameters of the CSS_image_crop? Where do you get all of those numbers |bSize=400|cWidth=100|cHeight=100|oTop=180|oLeft=60 ? I just need to mark the image area and then copy the code for instant use. Is it possible to make CSS_image_crop template compatible with ImageNote template? At least they could have the same names of parameters. Then it could be possible to copy code between those templates. Suggestion: Make parameters compatible between those two templates. --Snek01 (talk) 10:44, 20 November 2016 (UTC)[reply]
You are right, CSS_image_crop is not what we need. I think that your idea of being able to use the boxes of ImageNote as cropped images is brilliant. I have been using CropTool, but your method would be better, because it avoids creating multiple pages that need to be maintained and ensures that the provenance of the subimages is available. I would just use a better a id for the subimage and perhaps allow for further description in the annotation, then user would just have to include:
[[File:Materialien zur Naturgeschichte der Insel Celebes (1898) (14593986718).jpg#Tylomelania connectens shell|thumb|Tylomelania connectens]]
So the # would be used to specify the subimage selected. Regards, Aracali (talk) 16:18, 20 November 2016 (UTC)[reply]
I think, that the the solution should be compatible with ImageNote, but it should also be independent. The image viewed on the Wikipedia should not be altered, when any user will change a note on the image at Commons. Therefore all parameters of the rectangle should be used. Not just ID only. - But the positition just behind the file name is a good idea. Whatever the rectangle will be specified. --Snek01 (talk) 19:38, 20 November 2016 (UTC)[reply]
  • I have found the new cropping tool on commons (left sidebar) to be amazing at creating new cropped versions of pictures. Doc James (talk · contribs · email) 19:30, 19 November 2016 (UTC)[reply]
  • What we need is an easy way to upload a derivative of an image, which automatically keeps the source image's metadata, and links the two files via the version field. In other words, in addition to the "upload new version" button, we also need an "upload derivative version" button. JMK (talk) 22:52, 19 November 2016 (UTC)[reply]
Better cropping tool would be also good, but this is not the case or solution for this suggestion. (There are number of additional problems when uploading a new derived file. When I upload an PNG derived file made from JPG source file, how to keep metadata, etc.) When you already change levels, colors and remove background of the edited image, then uploading is just an insignificant part of the work. But when you just need to view an unaltered part of the image on the Wikipedia, then there is no need to upload anything. Cropping/uploading tool would save only some steps of this work. It will save only four of seven steps. 1) download the image, 2) crop it, 3) upload the image, 4) add links to source image and add link from source file to derived file. There will still need to: 5) create new descriptive name, 6) add proper description, 7) add categorization. Moreover just a cropping tool is not useful at all in cases when 1) linking to full image is preferred and 2) when there appear the cropped image to be only temporal solution. The more files need two times or more times work. Could you imagine to categorize of 300.000 instead of 100.000 just by yourself? Categorization is just tip of an iceberg. There are usually number of description improvements needed in files. --Snek01 (talk) 15:13, 20 November 2016 (UTC)[reply]
  • One advantage of this proposal over creating a new file with the cropped image is that the editor placing the cropped image (and other editors as well) could easily adjust the portion of the original image that is displayed, based on how it looks in the article. Small touch-ups can often make a big difference, but with the current scheme they are too much trouble. An adjustment might also be warranted if the article was edited or if other images were added. Quite a few full images in articles could benefit from a little bit of cropping. I think this feature would be widely used.--ArnoldReinhold (talk) 16:58, 30 November 2016 (UTC)[reply]

I was canvassing in the related wikiproject: en:Wikipedia talk:WikiProject Gastropods#2016 Community Wishlist Survey. --Snek01 (talk) 21:41, 1 December 2016 (UTC)[reply]

@ Vachovec1, thanks for your comment. This feature will be applied to images, that are expected to not be altered by cropping (see examples above). I can imagine only one way how could be the original image altered: with uploading higher resolution version over the file. It may or may not be recommended, but it can happen. Then would happen the same thing, that is happenning to Image Notes. (I did not test that, but I think, that Notes will move a bit.) If the user will use the rectangular part, then the Image Note will stay in the code of the image description. Uploader of the image should be responsible enough to avoid such problems. How many times a user damaged Image Notes when he uploaded larger version of file? I think, there is not known such case. It is not probable, that it will be a problem in this feature too. --Snek01 (talk) 21:41, 1 December 2016 (UTC)[reply]

Voting – Display rectangular part of the image as parameter of File

  1.   Support--Aracali (talk) 15:00, 28 November 2016 (UTC)[reply]
  2.   Support Sadads (talk) 15:31, 28 November 2016 (UTC)[reply]
  3.   Support JAn Dudík (talk) 22:04, 28 November 2016 (UTC)[reply]
  4.   Support Gareth (talk) 06:28, 29 November 2016 (UTC)[reply]
  5.   Support --Jan.Kamenicek (talk) 00:32, 30 November 2016 (UTC)[reply]
  6.   Support --Jarekt (talk) 03:43, 30 November 2016 (UTC)[reply]
  7.   Support --ArnoldReinhold (talk) 16:58, 30 November 2016 (UTC)[reply]
  8.   Support JoJan (talk) 14:37, 1 December 2016 (UTC)[reply]
  9.   Oppose Although I can see the benefits, I see a big problem too. When someone alters the source picture (let say there would be a cropping on the left side), all the parameters specifying the "cropped" rectangles would be off. The manual tweaking of those would be hell. So if you implement this, you can basically forget about the altering of the original picture. --Vachovec1 (talk) 20:31, 1 December 2016 (UTC)[reply]
  10.   Support just mentioned on irc how strange it was that we don't have this feature. The policy at COM:OVERWRITE ensures that no big changes should happen to existing files. Multichill (talk) 20:35, 1 December 2016 (UTC)[reply]
  11.   Support --MB-one (talk) 20:42, 1 December 2016 (UTC) I keep wondering for yearsnow, why this isn't implemented.[reply]
  12.   Support —Justin (koavf)❤T☮C☺M☯ 03:57, 2 December 2016 (UTC)[reply]
  13.   Support Draceane (talk) 10:29, 2 December 2016 (UTC)[reply]
  14.   Support Railwayfan2005 (talk) 23:06, 3 December 2016 (UTC)[reply]
  15.   Support --β16 - (talk) 11:19, 5 December 2016 (UTC)[reply]
  16.   Support--EftichiaKosma (talk) 7:51, 7 December 2016 (UTC)
  17.   Support — Rhododendrites talk \\ 22:23, 7 December 2016 (UTC)[reply]
  18.   Support →Spiritia 08:11, 10 December 2016 (UTC)[reply]
  19.   Support 4nn1l2 (talk) 23:54, 10 December 2016 (UTC)[reply]
  20.   Support - DPdH (talk) 12:10, 11 December 2016 (UTC)[reply]
  21.   Support, while there are means to do it know an easier solution would be welcome — NickK (talk) 13:52, 12 December 2016 (UTC)[reply]
  22.   Support --Yann (talk) 23:14, 12 December 2016 (UTC)[reply]

LaTeX-style referencing for images and equations

  • Problem:
1) Images The main purpose of images in articles is to illustrate the text. Refering to an image one has to either
  • number all images manually and keep track of the numbers and references which is error-prone, especially in a collaborative project
  • refer to them as "the diagram" which is ambiguous in case there are several diagrams
  • "the following/right/left diagram" which can be incorrect if the article is not viewed using a default desktop environment
  • completely describing them like "in the illustration where the magnetic field lines are shown in blue..." where the reader has to know what the picture looks like or read and understand all descriptions of the other pictures
2) Equations For equations the problem is even more severe since they have neither captions nor unique names and understanding what "the above definition" means often requires profound knowledge of the subject. There are some improvised solutions like w:en:Template:EquationRef and one can refer to an equation <math id="Pythagoras">a^2 + b^2 = c^2</math> with [[#Pythagoras]], but the ids are not displayed.
3) All methods above have the disadvantage that an editor might change a picture or equation without realizing that the referencing in the text gets confusing or wrong.
  • Who would benefit: Readers and editors alike. Especially important for long scientific articles and wikibooks.
  • Proposed solution: The following LaTeX syntax is just for explaining the principle. For a possible solution using wikitext see "Community discussion".
  • Editors can label pictures and equations with \label{some_name_chosen_by_the_editor}
  • All images and formulas that were assigned a label are numbered automatically and their number is shown next to them
  • The editor refers to the image with \ref{some_name_chosen_by_the_editor}
  • \ref{some_name_chosen_by_the_editor} is automatically replaced by the appropriate number of the image/formula
  • In case the image/formula with \label{some_name_chosen_by_the_editor} does not exist or was deleted, an error is displayed
  • More comments: The same problem can exist for tables, but usually there are only few tables in an article, they get rarely changed and can be given self-explanatory names. Priority should be given to images (used in many articles) and equations (mandatory for comprehensible articles). The actual numbering should be customized in each wiki. For example fig.1, fig.2... for images in en-wiki (1) (2)... for equations in en-wiki or (1.1) (1.2)... in wikibooks where the first number refers to the chapter in the book.

Community discussion

i sort of can get behind this idea, but I would suggest not further complicating wikicode syntax by mixing more latex into it. —TheDJ (talk • contribs) 00:10, 16 November 2016 (UTC)[reply]

@TheDJ:I chose the LaTeX syntax in my example because it is used in almost all scientific papers. In wikitext it will probably look different, for example
  • Wikitext:
:<math id="Pythagoras">a^2 + b^2 = c^2</math>
The resulting equation <ref name="Pythagoras" / > is known as Pythagoras theorem.
  • Result:
 
The resulting equation (1) is known as Pythagoras theorem.
Labeling of the equation can already be done in two equivalent ways using either the id parameter or by using \label{Pythagoras} inside the formula. The only thing that would have to be implemented is assigning and displaying a number at the end of the formula and a way to make <ref> display this number. This way it would not require any new syntax and the resulting wikitext is less complicated than the current solution using w:en:Template:EquationRef.--Debenben (talk) 01:54, 20 November 2016 (UTC)[reply]
Similar example for pictures
  • Wikitext:
[[Image:Fesoj - Papilio machaon (by).jpg|thumb|id=butterfly|butterfly on flower]]
In figure <ref name="butterfly" /> the butterfly is sitting on a flower.
  • Result:
 
Fig. 1: butterfly on flower
In figure 1 the butterfly is sitting on a flower.
Here one would have to introduce the additional id parameter. In case people think this adds too much complication to the wikicode, they may not use it or disable this feature for certain wikis and only use the referencing of equations, which would be a huge improvement on its own.--Debenben (talk) 03:47, 20 November 2016 (UTC)[reply]

Voting – LaTeX-style referencing for images and equations

  1.   Support --Boehm (talk) 14:01, 28 November 2016 (UTC)[reply]
  2.   Support --Debenben (talk) 12:28, 29 November 2016 (UTC)[reply]
  3.   Support --Una giornata uggiosa '94 · So, what do you want to talk about? 00:08, 1 December 2016 (UTC)[reply]
  4.   Oppose I think, that numbering of images is not allowed intentionally. There is normally possible to link to images with wikilink or with wikilink between ref tags like this <ref>[[:File:Fesoj - Papilio machaon (by).jpg]].</ref> Numbering of equations is also not needed. Equations on the certain page has no precedence over the equations anywhere else. There should be possible to link to equations on another page in the same way as on the actual page. Numbering is not the solution. Existing solutions of linking to equations are sufficient. --Snek01 (talk) 00:05, 2 December 2016 (UTC)[reply]
  5.   Support--Sannita - not just another it.wiki sysop 13:53, 2 December 2016 (UTC)[reply]
  6.   Support -- MichaelSchoenitzer (talk) 10:23, 3 December 2016 (UTC)[reply]
  7.   Support --β16 - (talk) 11:19, 5 December 2016 (UTC)[reply]
  8.   Support ---<(kmk)>- (talk) 23:59, 5 December 2016 (UTC) The inability to transparently refer to a specific image is a long standing weakness of mediawiki. Let's embrace the time proven customs to refer to an image in the main text than.[reply]
  9.   Support --Alexmar983 (talk) 08:55, 8 December 2016 (UTC)[reply]
  10.   Support →Spiritia 08:13, 10 December 2016 (UTC)[reply]
  11.   Support – Uanfala (talk) 01:12, 12 December 2016 (UTC)[reply]

Transcode audio files to MP3

Community discussion

Likely trivial from a technical standpoint, but this should not be done until the remaining mp3 patents expire (April 2017). -FASTILY 21:18, 17 November 2016 (UTC)[reply]

Voting – Transcode audio files to MP3

  1.   Support --Jarekt (talk) 03:48, 30 November 2016 (UTC)[reply]
  2. Conditional   Support per my comment above. -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  3.   Support --Gestumblindi (talk) 21:52, 1 December 2016 (UTC) As soon as the last MP3 patents expire in 2017.[reply]
  4. Weak   Support per Fastily. NMaia (talk) 01:06, 2 December 2016 (UTC)[reply]
  5.   Support Per the similar wishlist item. —Justin (koavf)❤T☮C☺M☯ 03:58, 2 December 2016 (UTC)[reply]
  6.   Support per Fastily. Richard Nevell (WMUK) (talk) 10:57, 6 December 2016 (UTC)[reply]
  7.   Support--Ranjithsiji (talk) 11:09, 6 December 2016 (UTC)[reply]
  8.   Support with correct metadata if possible.--Yodaspirine (talk) 18:11, 6 December 2016 (UTC)[reply]
  9.   Support Per Fastily. Until then, I've been told by insiders, this sort of thing would be very expensive to license on an annual basis (unless we do it the year before the patents expire). Daniel Case (talk) 05:38, 8 December 2016 (UTC)[reply]
  10.   Support Miniapolis 20:12, 9 December 2016 (UTC)[reply]
  11. Conditional   Support per Fastily; additionally, I'd prefer if we offered Opus versions, if the browser supports it, and only fallback to mp3 otherwise. --Waldir (talk) 11:57, 10 December 2016 (UTC)[reply]
  12.   Support per Fastily. —Ynhockey (talk) 16:13, 10 December 2016 (UTC)[reply]
  13.   Support--David1010 (talk) 20:31, 11 December 2016 (UTC)[reply]
  14. Conditional   Support per Fastily — NickK (talk) 13:54, 12 December 2016 (UTC)[reply]

Notifications for when your image is used

  • Problem: This is less a problem and more an idea for increasing the feelgood factor of editing Wikimedia projects. The idea is that the user who uploads an image file (on Commons or any other project) gets a notification whenever that file is used anywhere on Wikimedia – a bit like being pinged. This would show users that their work is being used and so give a quick rush of satisfaction similar to receiving thanks for an edit.
  • Who would benefit: Users who upload media files.
  • Proposed solution:

Community discussion

  • Even nicer if notified of 3rd Party use/infringement. Dispenser (talk) 15:53, 18 November 2016 (UTC)[reply]
  • Agree, it would go a long way towards incentivizing people to add/improve images. --SSneg (talk) 17:01, 19 November 2016 (UTC)[reply]
  • I disagree with this idea. There already is the feature showing the "File usage on Commons" and "File usage on other wikis". 1) Notifications from users should have precedence over the system alerts. The more images the user will upload, the less important this feature is. 2) Users should use their own images by themselves; not just upload them and wait what will happen. When I upload the image, then I will add it to the article and I will add it to the articles to wikipedias in other languages. If is an user unable to add his own image into the Chinese/Arabic/Hebrew/... Wikipedia, then he does not need to be notified, that his image is used there. Images can be added and immediately removed by another user. The author can be disappointed instead of motivated. 3) Should the user be notified about all images he uploaded or about images, where is he/she listed as an author? I am not interested to be notified about usage of image I uploaded. Moreover I am not interested in global usage of images that I created by myself. Maybe it could be interesting to see, if my images were used in Main page of other Wikipedias only, but nothing more. 4) This feature should not be default. This should not be a part of Wikimedia Software. This can be maximally as a gadget, that a user must turn on by himself actively. --Snek01 (talk) 15:14, 29 November 2016 (UTC)[reply]
  • @Ham II: Please also see: ""MediaChanges" feed to track pages where images are used" - you both appear to be proposing the same thing. --Fixuture (talk) 21:08, 30 November 2016 (UTC)[reply]
  • An alternative to this may be to have a bot which can give periodic reports on image use. We already have glamorous, which can show all uses within a category, uploaded, by a user, etc. Perhaps that could be used to compare usage month-to-month and provide an update to users who want it. I was excited about this at first, but the more I think about it, and reading the concerns of others, I don't know how productive it'll be. So weak support. — Rhododendrites talk \\ 22:28, 7 December 2016 (UTC)[reply]

Voting – Notifications for when your image is used

  1.   Support--Wesalius (talk) 07:01, 28 November 2016 (UTC)[reply]
  2.   Support, a nice idea. Sometimes I go through my uploads and check if/where they are used. --Stryn (talk) 12:32, 28 November 2016 (UTC)[reply]
  3.   Support -Nocowardsoulismine (talk) 19:01, 28 November 2016 (UTC)[reply]
  4.   Support MichaelMaggs (talk) 20:17, 28 November 2016 (UTC)[reply]
  5.   Support JAn Dudík (talk) 22:04, 28 November 2016 (UTC)[reply]
  6.   Support Gareth (talk) 06:30, 29 November 2016 (UTC)[reply]
  7.   Support IKhitron (talk) 12:15, 29 November 2016 (UTC)[reply]
  8.   Oppose per above in Community discussion. --Snek01 (talk) 15:14, 29 November 2016 (UTC)[reply]
  9.   Support Guycn2 · ☎ 19:04, 29 November 2016 (UTC)[reply]
  10.   Support --Telaneo (User talk page) 22:00, 29 November 2016 (UTC)[reply]
  11.   Support but the users should have a possibility to disable the notification in their settings if they did not like it. --Jan.Kamenicek (talk) 00:39, 30 November 2016 (UTC)[reply]
  12.   Support --Jarekt (talk) 03:49, 30 November 2016 (UTC)[reply]
  13.   Support --Micru (talk) 12:38, 30 November 2016 (UTC)[reply]
  14.   Support it would be a very positive notification and brighten my day as an editor. Ainali (talk) 15:53, 30 November 2016 (UTC)[reply]
  15.   Support --Fixuture (talk) 21:08, 30 November 2016 (UTC)[reply]
  16.   Oppose Poor use of developer time, and potentially an unwanted spam-like feature. -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  17.   Oppose Agreed with Fastily. This is a pure waste of Community Tech development time; I'm sure one of the WMF's feel-good (umm...) "feature" development teams would take this on. MER-C (talk) 05:21, 1 December 2016 (UTC)[reply]
  18.   Support --Gestumblindi (talk) 21:54, 1 December 2016 (UTC)[reply]
  19.   Support NMaia (talk) 01:06, 2 December 2016 (UTC)[reply]
  20.   Support Libcub (talk) 02:45, 2 December 2016 (UTC)[reply]
  21.   Support Since this is a de facto standard and is about to be open. —Justin (koavf)❤T☮C☺M☯ 03:52, 2 December 2016 (UTC)[reply]
  22.   Support Draceane (talk) 10:21, 2 December 2016 (UTC)[reply]
  23.   Support --Framawiki (talk) 20:46, 2 December 2016 (UTC)[reply]
  24.   Support // Martin Kraft (talk) 23:55, 2 December 2016 (UTC)[reply]
  25.   Support SamanthaNguyen (talk) 01:30, 3 December 2016 (UTC)[reply]
  26.   Neutral not high priority. Doc James (talk · contribs · email) 04:05, 3 December 2016 (UTC)[reply]
  27.   Support --Yiyi (talk) 15:33, 3 December 2016 (UTC)[reply]
  28.   Support Pamputt (talk) 11:05, 4 December 2016 (UTC)[reply]
  29.   Support --By erdo can (talk) 14:17, 4 December 2016 (UTC)[reply]
  30.   Support--Praveen:talk 13:06, 5 December 2016 (UTC)[reply]
  31.   Oppose per Fastily. --Tryptofish (talk) 00:13, 6 December 2016 (UTC)[reply]
  32.   Support Nice encouragement for uploaders; may be incentive for people who take part in competitions like WLM to keep contributing. Richard Nevell (WMUK) (talk) 10:52, 6 December 2016 (UTC)[reply]
  33.   Support--Ranjithsiji (talk) 11:10, 6 December 2016 (UTC)[reply]
  34.   Oppose Per Fastily. Ï am afraid of "spamming" too. There are users with thousands of uploads. If this goes live, they could be literally spammed by notifications. This proposal is well meant but serious rethinking is needed. --Vachovec1 (talk) 18:10, 6 December 2016 (UTC)[reply]
  35.   Support --Ανώνυμος Βικιπαιδιστής (talk) 21:17, 6 December 2016 (UTC)[reply]
  36.   Support--EftichiaKosma (talk) 7:51, 7 December 2016 (UTC)
  37.   Weak support per comments above — Rhododendrites talk \\ 22:28, 7 December 2016 (UTC)[reply]
  38.   Support But I have an even better idea: allow users to create a watchlist of images that they would be like to be informed about the use of. This would help us better control fair use, especially on wikis that do not allow it. Daniel Case (talk) 05:35, 8 December 2016 (UTC)[reply]
  39.   Support Ayack (talk) 11:57, 9 December 2016 (UTC)[reply]
  40.   Support --Nikola (talk) 18:44, 9 December 2016 (UTC)[reply]
  41.   Support --Tarjeimo (talk) 23:10, 9 December 2016 (UTC)[reply]
  42.   Support Even better if, apart of "pinging", a dynamic special page is being maintained per user. →Spiritia 08:16, 10 December 2016 (UTC)[reply]
  43.   Support --OrsolyaVirág (talk) 13:19, 10 December 2016 (UTC)[reply]
  44.   Support -- largely similar to my similar proposal ""MediaChanges" feed to track pages where images are used", Sadads (talk) 15:30, 10 December 2016 (UTC)[reply]
  45.   Support 4nn1l2 (talk) 23:55, 10 December 2016 (UTC)[reply]
  46.   Support - Useful metric. DPdH (talk) 12:11, 11 December 2016 (UTC)[reply]
  47.   Support--David1010 (talk) 20:31, 11 December 2016 (UTC)[reply]
  48.   Support, make it work the same way as Page link notification. Not sure I will want to use this feature but this is useful — NickK (talk) 13:56, 12 December 2016 (UTC)[reply]
  49.   Support--Mikheil Talk 21:17, 12 December 2016 (UTC)[reply]
  50.   Support --Yann (talk) 23:15, 12 December 2016 (UTC)[reply]

Pick a thumbnail for an article's associated page image

  • Problem: The thumbnail that is associated with an article, is automated, and sometimes imperfect. The thumbnail is used in various places, such as the mw:Page information, Mobile Apps, Hovercards, and the Project Portal search suggestion results. Editors cannot easily override the automatically-selected image. Most of the times, there's no problem with the picture the program picked (especially when there aren't too many images in the article), but sometimes, the thumbnail is not what we wish for. For example, while having Hebrew as the main language in the app, the article about Israel's late president Shimon Peres, had the graveyard area map in the small thumbnail, instead of, of course, one of his pictures.
  • Who would benefit: Readers and Editors
  • Proposed solution: Editors should be able to add a certain indication in the code of the article regarding the picture that should be used for the thumbnail. This can be a certain "magic word" that should be added inside the [[File:___|thumb]] of a relevant picture (maybe only one used in Infobox templates). (phab:T91683). Alternatively, this should be something managed in the Wikidata entry, (phab:T95026) but then, there's a problem when the only picture available is in Fair Use for example, and does not serve Wikipedias in all languages.

Community discussion

@Quiddity (WMF): Hi, thanks for the info I haven't been aware of. As you obviously understand this issue better than me, I would prefer leaving any changes in the description to you. You clearly got the point, so feel free to update it or add any needed clarifications. In case this issue is not relevant to the Wishlist Survey, it may be moved to any other page and the Phabricator will fit the needs. Thanks. Ldorfman (talk) 16:38, 23 November 2016 (UTC)[reply]
@Ldorfman: Done. I've rewritten it like so, and linked 2 related phabricator tasks which have more discussion on each of the possible solutions. :-) Quiddity (WMF) (talk) 20:39, 23 November 2016 (UTC)[reply]
Great.   Thank you, Quiddity. Ldorfman (talk) 17:00, 24 November 2016 (UTC)[reply]

Voting – Pick a thumbnail

  1.   Support – I've been looking for such an option for years! The automatic thumbnail is often not the best one. Guycn2 · ☎ 19:06, 29 November 2016 (UTC)[reply]
  2.   Support --Jan.Kamenicek (talk) 00:42, 30 November 2016 (UTC)[reply]
  3.   Support, really needed now as those thumbnails are featured in the app and the hovercards (still in beta but probably not for much longer). --Fixuture (talk) 21:11, 30 November 2016 (UTC)[reply]
  4.   Support --Una giornata uggiosa '94 · So, what do you want to talk about? 23:35, 30 November 2016 (UTC)[reply]
  5.   Support This could be very useful. --Vachovec1 (talk) 20:12, 1 December 2016 (UTC)[reply]
  6.   Support — KPFC 💬 23:21, 1 December 2016 (UTC)[reply]
  7.   Support SamanthaNguyen (talk) 01:30, 3 December 2016 (UTC)[reply]
  8.   Support, this will make PageImage Extension useful, finally. It is an abomination that this content decision is currently made by WMF and their stupid, intransparent algo ("The page image is chosen based on a number of criteria with limited documentation."). --Atlasowa (talk) 22:32, 4 December 2016 (UTC)[reply]
  9.   Support --Gestumblindi (talk) 02:18, 5 December 2016 (UTC)[reply]
  10.   Support Pick the image from wikidata P18--β16 - (talk) 11:22, 5 December 2016 (UTC)[reply]
  11.   Support -<(kmk)>- (talk) 17:03, 5 December 2016 (UTC) may I ask why anyone thought script driven choice of thumbnails would provide a better job than human editors?[reply]
  12.   Support --Andropov (talk) 17:18, 5 December 2016 (UTC)[reply]
  13.   Support -- Aspiriniks (talk) 18:15, 5 December 2016 (UTC)[reply]
  14.   Oppose This would conflict with hot-button issues over infoboxes at some projects. --Tryptofish (talk) 00:15, 6 December 2016 (UTC)[reply]
  15.   Support--Ranjithsiji (talk) 11:10, 6 December 2016 (UTC)[reply]
  16.   Support →Spiritia 08:26, 10 December 2016 (UTC)[reply]
  17.   Support --Waldir (talk) 11:29, 10 December 2016 (UTC)[reply]
  18.   Support using a Wikidata property. --NaBUru38 (talk)
  19.   Support Hovercards, etc., ignoring the first image, usually in an infobox, and picking the second, which may be something else entirely that just happens to be associated with some event mentioned in the article, is a seriously confusing problem. I ran across a case the other day where someone's bio came up with a picture of a destroyed building, and another where it was a lizard.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:21, 11 December 2016 (UTC)[reply]
  20.   Support, if there are applications or features that pick thumbnails we should be able to select these thumbnails — NickK (talk) 13:58, 12 December 2016 (UTC)[reply]

Position Maps & Media Viewer

Machine translation from German to English, please improve!

  • Problem: In boxes, often positions on cards are indicated by a symbol (called POSKARTE in DE-Wiki). If you enlarge it using the Media Viewer, only the pure file without the position symbol will be displayed. It would be much to wish that this would be possible in the future. I mean, as long as the page with the position is still called and the map is only shown, and not after the map itself has been called. In these cases, the name of the place (eg a mountain) is still under the inserted map, and its position would still be available, but it is currently not shown on the map. This is also the case in other wikis (eg in the Englich), so to this extent a "commons" -application.
In Boxen werden vielfach Positionen auf Karten durch ein Symbol angezeigt (in DE-Wiki POSKARTE genannt). Wenn man diese mit Hilfe des Media Viewers vergrößert, wird nur die reine Datei ohne das Positions-Symbol angezeigt. Es wäre sehr zu wünschen, wenn dies in Zukunft ermöglicht würde. Ich meine, solange die Seite mit der Position noch aufgerufen und die Karte nur eingeblendet ist und nicht nachdem die Karte selbst aufgerufen wurde. In diesen Fällen steht unter der eingeblendeten Karte nämlich noch der Name des Ortes (z. B. ein Berg) und wäre seine Position noch verfügbar, doch auf der Karte ist er (derzeit leider) nicht dargestellt. Dies ist in anderen Wikis (z. B. im Englichen) ebenso, insoweit also eine "Commons"-Angelegenheit.
  • Who would benefit:
  • Proposed solution: Superimposed dot markers used by map templates to indicate a position on the map, to be reflected in MediaViewer
  • Phabricator tickets:

Community discussion

The user wants superimposed dot markers used by map templates to indicate a position on the map, to be reflected in MediaViewer. —TheDJ (talk • contribs) 20:06, 11 November 2016 (UTC)[reply]

E.g. w:en:Wikipedia:WikiProject_Maps/Conventions#Location_maps. Quiddity (WMF) (talk) 01:03, 23 November 2016 (UTC)[reply]
This is, what I mean; but it does not work in normal Wikipedia. --FkMohr (talk) 14:00, 15 November 2016 (UTC)[reply]
Well, it will - likely before this survey will be over ;) Max Semenik (talk) 22:39, 16 November 2016 (UTC)[reply]
Moved from here where to? --FkMohr (talk) 14:00, 15 November 2016 (UTC)[reply]

Voting – Position Maps & Media Viewer

  1.   Support I think this is needed as long as Kartographer doesn't appear (and probably also after it will, because I think transition from present locator map templates will take much time). If this is not feasible, then Media Viewer should stop enlarging these pictures. The reader of an article like it:Contigliano clicks on the picture of Italy to see where Contigliano is, he probably already knows how Italy looks like and there's no point in enlarging Italy alone if the red dot is not displayed too. --Una giornata uggiosa '94 · So, what do you want to talk about? 00:24, 1 December 2016 (UTC)[reply]
  2.   Support -- MichaelSchoenitzer (talk) 10:29, 3 December 2016 (UTC)[reply]
  3.   Support --Yiyi (talk) 15:35, 3 December 2016 (UTC)[reply]
  4.   Support - Akela (talk) 22:01, 8 December 2016 (UTC)[reply]
  5.   Support --TanvirH (talk) 20:34, 10 December 2016 (UTC)[reply]

Reduce size of Play Button in Videos

  • Problem: Videos in articles destroy the layout of articles due to the placement of the play-button. I would prefer a small play button in the text line of the thumb-pics or a small play-button in the lower left edge of the pictures.
  • Who would benefit: Reader and authors
  • Proposed solution:

Community discussion

Voting – Reduce size of Play Button in Videos

  1.   Support making global the enwiki resize of video play button! --Atlasowa (talk) 14:00, 5 December 2016 (UTC)[reply]
  2.   Support --TanvirH (talk) 20:35, 10 December 2016 (UTC)[reply]
  3.   Support --NaBUru38 (talk)

Slideshow support

 
A slider widget (one of many styles)
 
Slide show in Xubuntu 16.04
  • Problem:"A picture is worth a thousand words".Slide show is a mainstream image/interactive media viewer platform .all major desktop & mobile web browser support slideshow. Most people respond to visual content, and they respond strongly.we have one .but it's not mature enough .we need a slideshow for text & gallery in "Article" .it should have progress bar , Auto-play/timed transitions, Print mode & PDF export.
  • Who would benefit: Readers and editors of wikis .wikipedia technical articles, architecture and nature related article would benefit. Wikiversity learning resources, learning projects, and research will get benefit. media file repository commons will be able to represent there media in an unique way. Anyone can edit; easy to use and learn.
    A well-organized slide show allows a presenter to fit visual images to an oral presentation. editor's & wiki reader's will get benefit.
  • Phabricator tickets:

Community discussion

hi Sam Wilson , thank you for your response. Ahm masum (talk) 09:17, 17 November 2016 (UTC)[reply]

  • @Ahm masum: I'm afraid that this proposal misses a description of a problem that you would like to see solved. "Put random features into some slider gadget" could be one solution for some problem, but that requires knowing the problem first. :) Could you please describe it? --AKlapper (WMF) (talk) 12:40, 15 November 2016 (UTC)[reply]

hi Andre Klapper , thank you for your response. Ahm masum (talk) 09:17, 17 November 2016 (UTC)[reply]

  • Thanks for bringing this to my attention, @Samwilson:. phab:T138665 is an attempt to have embedded SVGs. The thing to be careful about is that some users might still want to print pages – how will slideshows be handled? For what it's worth, a long long time ago, I suggested the following but it didn't gain any traction. Cheers, cmɢʟee⎆τaʟκ 20:20, 15 November 2016 (UTC)[reply]

hi cmɢʟee⎆τaʟκ , thank you for your response. please leave your suggestions here, T150932 . THANKS. Ahm masum (talk) 09:17, 17 November 2016 (UTC)[reply]

Slider demo 
<html><head><title>Slider demo</title></head><body onload="init();"><script>
var data = [
 { label:'Dodecahedron', content:'In geometry, a dodecahedron is any polyhedron with twelve flat faces, but usually a regular dodecahedron is meant: a Platonic solid. It is composed of 12 regular pentagonal faces, with three meeting at each vertex, and is represented by the Schläfli symbol {5,3}. It has 20 vertices and 30 edges. Its dual polyhedron is the icosahedron, with Schläfli symbol {3,5}.', image:'http://upload.wikimedia.org/wikipedia/commons/c/c0/Uniform_polyhedron-53-t0.png' },
 { label:'Truncated dodecahedron', content:'In geometry, the truncated dodecahedron is an Archimedean solid. It has 12 regular decagonal faces, 20 regular triangular faces, 60 vertices and 90 edges.', image:'http://upload.wikimedia.org/wikipedia/commons/1/15/Uniform_polyhedron-53-t01.png' },
 { label:'Icosidodecahedron', content:'In geometry, an icosidodecahedron is a polyhedron with twenty triangular faces and twelve pentagonal faces. An icosidodecahedron has 30 identical vertices, with two triangles and two pentagons meeting at each, and 60 identical edges, each separating a triangle from a pentagon. As such it is one of the Archimedean solids and more particularly, a quasiregular polyhedron.', image:'http://upload.wikimedia.org/wikipedia/commons/5/57/Uniform_polyhedron-53-t1.png' },
 { label:'Truncated icosahedron', content:'In geometry, the truncated icosahedron is an Archimedean solid, one of thirteen convex isogonal nonprismatic solids whose faces are two or more types of regular polygon.', image:'http://upload.wikimedia.org/wikipedia/commons/6/63/Uniform_polyhedron-53-t12.png' },
 { label:'Icosahedron', content:'In geometry, an icosahedron is a regular polyhedron with 20 identical equilateral triangular faces, 30 edges and 12 vertices. It is one of the five Platonic solids.', image:'http://upload.wikimedia.org/wikipedia/commons/1/12/Uniform_polyhedron-53-t2.png' } ];

 var iActive;
 var nData = data.length;
 var el_slider;
 var el_slider_spaces = new Array(nData);
 var el_slider_thumbs = new Array(nData);
 var el_slider_labels = new Array(nData);
 var el_content = document.getElementById('content');
function init() {
 var el_slider_rows = new Array(nData);
 var el_slider_table = document.createElement('table');
 var el_slider_track = document.createElement('div');
 el_slider = document.getElementById('slider');
 el_slider.style.position = 'relative';
 el_slider.onmousewheel = on_mouse_wheel;
 if (window.addEventListener) {
  window.addEventListener('DOMMouseScroll', on_mouse_wheel, false);
 }
 el_slider_track.style.position = 'absolute';
 el_slider_track.style.border = '1px inset';
 el_slider_track.style.left = '8px';
 el_slider_track.style.width = 0;
 el_slider_track.style.height = '100%';
 el_slider_table.style.position = 'relative';
 for (var iData = 0; iData < nData; ++iData) {
  el_slider_spaces[iData] = document.createElement('td');
  // el_slider_spaces[iData].textContent = iData;
  el_slider_spaces[iData].style.padding = 0;
  el_slider_thumbs[iData] = document.createElement('div');
  //*
  el_slider_thumbs[iData].textContent = '\u2261\u2261\u2261'; //&equiv;
  // el_slider_thumbs[iData].textContent = '=';
  el_slider_thumbs[iData].style.fontSize = '5px';
  // el_slider_thumbs[iData].style.padding = '0 3px';
  /*/
  el_slider_thumbs[iData].style.padding = '2px 4px';
  //*/
  el_slider_thumbs[iData].style.borderRadius = '2px';
  el_slider_thumbs[iData].style.MozBorderRadius = '2px';
  el_slider_thumbs[iData].style.border = '2px outset';
  el_slider_thumbs[iData].style.background = '#aaaaaa';
  el_slider_thumbs[iData].style.color = '#cccccc';
  el_slider_labels[iData] = document.createElement('td');
  el_slider_labels[iData].textContent = data[iData].label;
  el_slider_labels[iData].style.lineHeight = '90%';
  // el_slider_labels[iData].style.textIndent = '-4px';
  el_slider_rows[iData] = document.createElement('tr');
  el_slider_rows[iData].onmousedown = on_mouse_down;
  el_slider_rows[iData].onmouseover = on_mouse_over;
  el_slider_spaces[iData].appendChild(el_slider_thumbs[iData]);
  el_slider_rows[iData].appendChild(el_slider_spaces[iData]);
  el_slider_rows[iData].appendChild(el_slider_labels[iData]);
  el_slider_table.appendChild(el_slider_rows[iData]);
 }
 el_slider.appendChild(el_slider_track);
 el_slider.appendChild(el_slider_table);
 activate(0);
}

function activate(iActivate) {
 if (iActivate >= 0 && iActivate < nData) {
  iActive = iActivate;
  for (var iData = 0; iData < nData; ++iData) {
   if (iData == iActivate) {
    document.getElementById('content').textContent = data[iData].content;
    document.getElementById('image').src = data[iData].image;
    el_slider_thumbs[iData].style.visibility = 'visible';
   } else {
    el_slider_thumbs[iData].style.visibility = 'hidden';
   }
  }
 }
}

function on_mouse_down(event) {
 var el = event.target;
 for (var iData = 0; iData < nData; ++iData) {
  if (el_slider_spaces[iData] == el || el_slider_labels[iData] == el) {
   activate(iData);
   break; // stop checking which cell mouse is in
  }
 }
 if (event) {
  if (event.preventDefault) { event.preventDefault(); }
  event.returnValue = false;
 }
}
function on_mouse_over(event) {
 if (buttonIsPressed) { on_mouse_down(event); }
}

function on_mouse_wheel(event) {
 var el = event.target;
 do {
  if (el == el_slider) {
   var delta = 0;
   if (!event) { delta = window.event.wheelDelta / 120; } // IE
   else if (window.opera) { delta = event.wheelDelta / -120; } // Opera
   else if (event.detail) { delta = event.detail / -3; } // Mozilla
   if (event.preventDefault) { event.preventDefault(); }
   event.returnValue = false;

   if (delta) { activate(iActive - (delta > 0 ? 1 : -1)); }
   break; // stop checking if wheel is over slider
  }
  el = el.parentNode;
 } while (el);
}

var buttonIsPressed = false;
document.body.onmousedown = function() { buttonIsPressed = true; };
document.body.onmouseup = function() { buttonIsPressed = false; };

</script>
<table border="1" cellpadding="4" cellspacing="0" width="50%">
 <tr><td colspan="2"><img id="image" width="100%"/></td></tr>
 <tr>
  <td valign="top" width="100">
   <div id="slider" title="Drag up/down or use scroll wheel"></div></td>
  <td><div id="content"></div></td>
 </tr>
</table>
</body></html>

Voting – Slideshow support

  1.   Oppose, I don't think that this would be useful for articles at all - it would be used on meta/project pages only. And there imo WebMs would be better. Also way too much development effort for how little use it has. --Fixuture (talk) 21:13, 30 November 2016 (UTC)[reply]
  2.   Oppose Eye candy sure, but I can't see this being so widely used as to warrant inclusion in core MediaWiki -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  3.   Support Libcub (talk) 02:46, 2 December 2016 (UTC)[reply]
  4.   Oppose Slideshows as a presentation of still images should not be used at Wikipedia at all. Slideshows including oral presentations would be fine, but there is w:webm video file format better for such purpose. --Snek01 (talk) 22:14, 4 December 2016 (UTC)[reply]
  5.   Oppose In some sense MediaViewer is already a slideshow system. However, I feel it would attract the wrong crowd. Unintuitively, WebM likely already has slideshow functionality built in (i-frames), the video player would only needs a "Halt" command. Dispenser (talk) 00:31, 11 December 2016 (UTC)[reply]

Support KML files for geodata

  • Problem: Basic problem is that KML files (Keyhole Markup Language, for geodata) cannot be uploaded, and so instead are stored as wikitext in subpages. This is sub-optimal for multiple reasons:
  1. There is no associated {{information}} template, for description, author, date, licence, information source, etc.
  2. The licence is restricted to the standard licence for a wikitext page, rather than being able to choose a different licence such as CC0 or CC-BY
  3. Categorisation is difficult, as including [[Category: ]] links at the end of the page breaks the KML file.
  4. Sharing between wikis is more complicated than it needs to be, as they aren't stored as files on Commons. A recent Wikidata innovation does allow KML subpages to be associated with relevant Wikidata items, and thus shared between wikis, but this is a workaround that requires a lua module to be setup and translated across wikis. Thus far the module has only be set up on five wikis.
  • Who would benefit: Readers and editors of wikis that have articles (or other pages) on linear/polygon geographic features (e.g. roads, railways, flight paths, rivers, parks, lakes, towns and other settlements, etc). So Wikipedias and Wikivoyages of any language are the most obvious use cases, and Wikidata items on such features, but other uses could be possible (if those wikis are interested), such as Commons (galleries/category pages about geographic features); maybe Wikiversity (e.g. perhaps mapping things such troop movements or bird migratory patterns could be useful?)
  • Proposed solution: Not sure what the best solution is. GeoJSON is probably the format of the future, i.e. for integration with mw:Maps, see this Phab comment: phab:T28059#2726773. So solutions could be/include:
    • Implement KML uploading to resolve the 6-year old request. Leave the issue of compatibility/incompatibility with mw:Maps and/or file format concersion for later.
    • Mass-convert existing KML subpages to GeoJSON files, once GeoJSON format is available (phab:T137930).
    • Allow a way to upload/download data as KML - doing an on-the-fly conversion to/from GeoJSON, which will be used for storage.

This is resubmit of 2015 Community Wishlist Survey/Commons#Support KML files in Commons (ranked #34 out of 107).

Community discussion

   application/vnd.google-earth.kml+xml
   application/vnd.google-earth.kmz

Question: would it be possible to use an open standard such as GML (or any other) by way of a conversion? Yes, I am aware KML is now an OGC open standard. GML's mime type is application/gml+xml. I suspect some people might be uncomfortable with content downloaded from Wikimedia suggesting a proprietary client. - Amgine/meta wikt wnews blog wmf-blog goog news 15:17, 8 November 2016 (UTC)[reply]

We are already in the process of supporting GeoJSON i think.. for these reasons. —TheDJ (talk • contribs) 15:29, 8 November 2016 (UTC)[reply]
  • Well I agree, but I would find a different reasoning or use. Basically nowadays there is no place to store personal KML files. Wikimedia Foundation does not run open map project, but KML files might be understood as media. KML files are not just routes, you have dont during your spare day, but also sets of point we use to list some object in Commons or Wikipedia. I guess there might be multiple good examples why we need to store kml files.--Juandev (talk) 17:07, 14 November 2016 (UTC)[reply]

Voting – Support KML files for geodata

  1.   Support --Rschen7754 03:15, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 07:01, 28 November 2016 (UTC)[reply]
  3.   Support - now KLM files are sort of mesh in template namespace JAn Dudík (talk) 22:06, 28 November 2016 (UTC)[reply]
  4.   Support Support of KML is needed to convert KML to GeoJSON. --Snek01 (talk) 15:28, 29 November 2016 (UTC)[reply]
  5.   Support --Zerabat (discusión) 19:41, 29 November 2016 (UTC)[reply]
  6.   Support --Jarekt (talk) 03:51, 30 November 2016 (UTC)[reply]
  7.   Support -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  8.   Support NMaia (talk) 01:34, 2 December 2016 (UTC)[reply]
  9.   Support. This will be a boon to voy:. —Justin (koavf)❤T☮C☺M☯ 03:53, 2 December 2016 (UTC)[reply]
  10.   Support--Sannita - not just another it.wiki sysop 13:52, 2 December 2016 (UTC)[reply]
  11.   Support -- Ryan • (talk) • 18:25, 2 December 2016 (UTC)[reply]
  12.   Support --jdx Re: 09:10, 3 December 2016 (UTC)[reply]
  13.   Support --Praveen:talk 13:49, 3 December 2016 (UTC)[reply]
  14.   Support --By erdo can (talk) 14:17, 4 December 2016 (UTC)[reply]
  15.   Support--Ranjithsiji (talk) 11:11, 6 December 2016 (UTC)[reply]
  16.   Support Daniel Case (talk) 05:38, 8 December 2016 (UTC)[reply]
  17.   Support --Ambre Troizat (talk) 12:13, 8 December 2016 (UTC)[reply]
  18.   Support Ayack (talk) 11:57, 9 December 2016 (UTC)[reply]
  19.   Support --Spencer (talk) 14:37, 9 December 2016 (UTC)[reply]
  20.   Support —Ynhockey (talk) 15:58, 10 December 2016 (UTC)[reply]
  21.   Support --TanvirH (talk) 20:35, 10 December 2016 (UTC)[reply]
  22.   Support well-organized proposals deserve support. 4nn1l2 (talk) 22:29, 10 December 2016 (UTC)[reply]
  23.   Support--David1010 (talk) 20:27, 11 December 2016 (UTC)[reply]
  24.   Support — NickK (talk) 14:02, 12 December 2016 (UTC)[reply]
  25.   Support --Elitre (talk) 18:56, 12 December 2016 (UTC)[reply]

Support SVG interactivity and animation in Media Viewer

  • Problem: Media Viewer displays SVGs as PNGs instead of SVGs, preventing useful interactivity such as those discussed here It's an unnecessary extra click, and new users may not know to do it.
  • Who would benefit: Readers
  • Proposed solution: Embed the SVG file in the Media Viewer chrome
  • More comments: Just in case anyone claims this is a security risk...
  1. SVGs are already vetted for scripts
  2. The user can click on the thumbnail on either Media Viewer or the file description page to get the SVG anyway

Community discussion

Hi cmglee, I moved your proposal here, to the Multimedia page. -- DannyH (WMF) (talk) 21:12, 22 November 2016 (UTC)[reply]

Voting – Support SVG interactivity and animation in Media Viewer

  1.   Support. Interactive SVG should be viewed in an interactive way by default. Not just a simple image. Without this feature the Wikipedia can not be considered as an interactive encyclopedia (and it is not per en:Wikipedia). --Snek01 (talk) 20:55, 29 November 2016 (UTC)[reply]
  2.   Support Pamputt (talk) 07:39, 1 December 2016 (UTC)[reply]
  3.   Support : Interactive SVG should be viewed, with a control or limited at Wikipedia only, in an interactive way by default. —— DePlusJean (from FR)
  4. Strong   Support // Martin Kraft (talk) 23:51, 2 December 2016 (UTC)[reply]
  5. Strong   Support --jdx Re: 09:13, 3 December 2016 (UTC)[reply]
  6. Strong   Support -- MichaelSchoenitzer (talk) 10:17, 3 December 2016 (UTC)[reply]
  7.   Support--Ranjithsiji (talk) 11:11, 6 December 2016 (UTC)[reply]
  8.   Oppose. Although I think it will be appropriate to directly serve SVG files so animation can be done someday, I do not think it is appropriate to do it right now even if we assume that all browsers now handle HTML 5/SVG. First, a very small percentage of SVG files have dynamic content, so most files are adequately represented by PNGs. Even files that have switch translations are adequately handled by serving PNGs. Although there are many switch-translated SVGs, there are probably vastly fewer animated SVGs. Some vendors even want to drop SMIL animation and force SVG animations to be script only; with that on the horizon, non-script animations do not have a certain future, and WM will not serve scripted SVGs anytime soon. File:First Ionization Energy.svg has both switch translations and mouseover activity, but it is rare. Animations are usually done with GIFs. Animations have other problems: they can look great on screen, but they are lifeless when printed. File size is a bigger issue. Switch translations are reasonable (low impact) for a few languages, but there are switch-translated files where the translations have added a couple hundred kilobytes to an already bloated SVG file; File:Map of USA with state names.svg with no switch translations was 260 kB; with translations 650 kB. Many SVG files are seriously bloated even without switch translations. A version of File:Gibraltar map-en-edit2.svg was a picture of the day, but the static SVG file is incredibly bloated at 1.8 MB; it is more efficient for a WP to serve a small precomputed PNG rather than a monstrous SVG. Although some SVG files are compact, editors such as Inkscape perversely produce bloated SVG; Inkscape apparently does not want any element inheriting any graphic trait. Furthermore, Inkscape misuses CSS styles. Even if SVG files were passed through svgo to clean them up, many will still be bloated because they have too much detail in their paths or have converted all their characters to curves because the human illustrator did not understand the issue with fonts. The SVG file issue is a mess, and there is no pressing need to start serving SVG files as a matter of course until some of those problems have been figured out. Should SVGs be switch translated or XLIFF+skeletoned? Maybe there could be a mechanism to serve particular SVGs or provide faster access (single click to SVG rather than click the file gets another PNG and then click that PNG to get to the actual SVG). Glrx (talk) 20:34, 9 December 2016 (UTC)[reply]
  9.   Support --TanvirH (talk) 20:36, 10 December 2016 (UTC)[reply]
  10.   Support, interactivity is a critical aspect of learning. --NaBUru38 (talk)
  11.   Support. If concern is that not all svg files have quality code and some are too big, then maybe make that svg will be displayed only if some special flag have been passed, like [[File:|svg|]]. --Similartothissimilartothat (talk) 18:18, 11 December 2016 (UTC)[reply]
  12.   Support — NickK (talk) 14:03, 12 December 2016 (UTC)[reply]

View object location of all images with coordinates on a map

Problem: There are being added coordinates of "camera location" to images with location template commons:Template:location. Position of all of those images are on the map.

The map is accesible via the "View this and other nearby images on: OpenStreetMap - Google Earth".

When a user will add coordinates of "object location" with the object location template commons:Template:object location, then the only one position from object location template (of the image where you just came from) is visible. But all other positions are from the camera location template.

There currently is no possibility to view more than one position of coordinates from object location on a map.

  • Who would benefit: Users who want to see all images from the certain area. Editors will see all images from the certain area for better categorization, they will also see areas, where are photos lacking from.
  • Proposed solution: It would be helpful to view all positions of camera location and all positions of object location on one map together. Ideally there would be helpful to have more possibilities. 1) view camera location only (this is what we have); 2) view both camera location and object location; 3) view object location only; 4) if there are both camera location and object location in one image, 4a) view both, 4b) view camera location only, 4c) view object location only.
  • More comments: Object location template is necessary, because there is not always helpful to add camera location or it may be even impossible to provide the camera location (that usually knows the only photographer).

That is so obvious requisite, that I was hoping there must exist such feature, but I did not find it and nobody knew about it. So I add it to this wishlist survey.

  • Phabricator tickets:

Community discussion

Seeing slightly related existing stuff like https://tools.wmflabs.org/wikishootme/ or https://wiki.openstreetmap.org/wiki/WIWOSM I wonder how complicate this would be... --AKlapper (WMF) (talk) 18:31, 21 November 2016 (UTC)[reply]

Hi Snek01, just a heads-up: I moved your proposal here, to the Multimedia page. -- DannyH (WMF) (talk) 01:12, 24 November 2016 (UTC)[reply]

Fixuture, WikiShootMe shows location of images, that uses camera location (Template:Location). WikiShootMe does not show location of images, that uses Template:object location. There is need to improve this tool, because it shows about a half of images locations. It will be non-controversial improvement. It will be also a relatively simple improvement, because the same method what is done with camera locations is needed to be done also with object locations. But its impact will be huge, because it will allow to maintenance and view/search for all images according to its location on map. --Snek01 (talk) 18:29, 3 December 2016 (UTC)[reply]
Commons-on-OSM is only the frontend for Geocommons. Geocommons is an tool from inactive user:Para, so I believe it needs an new maintainer and support for Template:object location. --Kolossos (talk) 17:42, 12 December 2016 (UTC)[reply]

Voting – View location of all images with coordinates on a map

  1.   Support --Jan.Kamenicek (talk) 00:45, 30 November 2016 (UTC)[reply]
  2.   Support I think we should have layers of links: camera location layer, object location layer, wikipedia article layer, etc. that could be turn on and off. As I mentioned in phabricator:T149280 I would propose to do it in the Kartographer. --Jarekt (talk) 04:02, 30 November 2016 (UTC)[reply]
  3.   Support--Praveen:talk 13:09, 5 December 2016 (UTC)[reply]
  4.   Support--Ranjithsiji (talk) 11:11, 6 December 2016 (UTC)[reply]
  5.   Support, to advance discussion about mapping all sorts of things including health statistics. More mapping tools helps everyone! Blue Rasberry (talk) 14:38, 8 December 2016 (UTC)[reply]
  6.   Support Please, make OpenStreetMap viewable on all wikis. --Schumi4ever (talk) 15:41, 8 December 2016 (UTC)[reply]
  7.   Support --Spencer (talk) 14:37, 9 December 2016 (UTC)[reply]
  8.   Support —Ynhockey (talk) 15:59, 10 December 2016 (UTC)[reply]
  9.   Support - DPdH (talk) 12:05, 11 December 2016 (UTC)[reply]
  10.   Support--David1010 (talk) 20:28, 11 December 2016 (UTC)[reply]
  11.   Support --Soluvo (talk) 00:51, 12 December 2016 (UTC)[reply]
  12.   Support--Mikheil Talk 21:18, 12 December 2016 (UTC)[reply]

Add DNG support (auto conversion to jpeg, Upload, Download)

  • Problem: The files on Commons are meant to be freely reused. Most images are offered in lossy jpeg format. Jpeg is a format to be viewed with the human eye. But it contains artifacts and therefore is not good for creating derivative versions. Photos on digital cameras are natively stored in the non-lossy DNG format that is free but not available on Commons. An alternative would be TIFF. Files uploaded in TIFF format to commons are auto converted to jpeg, when included in a Wikipedia page, but you can download the original TIFF. Lets expand this to DNG! DNG is actually TIFF, but restricted to one of the possible many TIFF encodings and with added MetaData.
  • Who would benefit: People contributing photos taken with a digital camera, people reusing this images
  • Proposed solution:
    • Allow DNG filename extension
    • extend TIFF to jpeg conversion to DNG to jpeg conversion
    • Display additional DNG metadata in EXIF section of file description pages
  • More comments: see also the proposal to allow other file types
  • Phabricator tickets:

Community discussion

Voting – Add DNG support

  1.   Oppose per my comment above. DNG is a proprietary, patent-encumbered format. -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  2.   Strong oppose per above. NMaia (talk) 01:37, 2 December 2016 (UTC)[reply]
  3.   Oppose : This format is a patented by Adobe Systems. —— DePlusJean (from FR)
  4.   Oppose per comments above. BJ Axel (talk) 08:12, 2 December 2016 (UTC)[reply]
  5.   Oppose Jmvkrecords ⚜ (Intra talk) 08:36, 2 December 2016 (UTC).[reply]
  6.   Oppose --Waldir (talk) 11:35, 10 December 2016 (UTC)[reply]
  7.   Support Sensible standardized TIFF extension and popular archival format.

    The patent claims seem to be FUD. The license Adobe provides seems similar to W3C approach to patent, to prevent embrace, extend and extinguish they grant a royalty free implementation for compliant en/decoders. Dispenser (talk) 00:53, 11 December 2016 (UTC)[reply]

  8.   Oppose, not sure this is a good idea. This is a non-free format and one of really many raw image formats. We really should not prefer one non-free non image format over another; moreover, we do not need to accept raw image formats in general as most photo hosting websites do not do this — NickK (talk) 13:35, 12 December 2016 (UTC)[reply]

3D models

  • Who would benefit: Entire community and users.
  • Proposed solution: First, enable upload. Second, code preview.

Community discussion

If we can display 3-D (perhaps by rotation, probably not with funny glasses), then we should be able to upload the proper files. Smallbones (talk) 18:00, 16 November 2016 (UTC)[reply]

Hi Smallbones, just a heads-up: I moved your proposal to the Multimedia page. -- DannyH (WMF) (talk) 01:06, 24 November 2016 (UTC)[reply]

  • Besides AMF, it could be worth looking at other potential formats, such as OBJ, STEP (an ISO standard), OpenMesh and OpenCTM. We should probably come up with a set of objective criteria to compare these (and maybe others), so that we aren't making an arbitrary or sub-optimal choice. --Waldir (talk) 12:25, 10 December 2016 (UTC)[reply]

I would like to ask, how is it related to this interactive 3D model inside the PDF file? http://journals.plos.org/plosone/article/file?type=supplementary&id=info:doi/10.1371/journal.pone.0023313.s001 Thanks! --Snek01 (talk) 23:52, 11 December 2016 (UTC)[reply]

Voting – 3D models

  1.   Support --Jan.Kamenicek (talk) 00:48, 30 November 2016 (UTC)[reply]
  2.   Support --Jarekt (talk) 04:03, 30 November 2016 (UTC)[reply]
  3.   Support --𝔊 (Gradzeichen Diſk✉Talk) 16:51, 30 November 2016 (UTC)[reply]
  4.   Support -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  5.   Support --EugeneZelenko (talk) 18:08, 1 December 2016 (UTC)[reply]
  6.   Support NMaia (talk) 01:39, 2 December 2016 (UTC)[reply]
  7.   Support Libcub (talk) 02:48, 2 December 2016 (UTC)[reply]
  8.   Support We need to support many more filetypes. —Justin (koavf)❤T☮C☺M☯ 03:53, 2 December 2016 (UTC)[reply]
  9.   Support Draceane (talk) 10:27, 2 December 2016 (UTC)[reply]
  10.   Support--Sannita - not just another it.wiki sysop 13:50, 2 December 2016 (UTC)[reply]
  11.   Support --Framawiki (talk) 20:45, 2 December 2016 (UTC)[reply]
  12.   Support --Saverio.G (talk) 00:08, 3 December 2016 (UTC)[reply]
  13.   Support Daylen (talk) 06:22, 3 December 2016 (UTC)[reply]
  14.   Support --jdx Re: 09:23, 3 December 2016 (UTC)[reply]
  15.   Support Jo-Jo Eumerus (talk, contributions) 09:31, 3 December 2016 (UTC)[reply]
  16.   Support – Susanna Ånäs (Susannaanas) (talk) 11:28, 3 December 2016 (UTC)[reply]
  17.   Support --Virginia Gentilini (talk) 13:07, 3 December 2016 (UTC)[reply]
  18.   Support --LikeLifer (talk) 17:49, 3 December 2016 (UTC)[reply]
  19.   Support --By erdo can (talk) 14:16, 4 December 2016 (UTC)[reply]
  20.   Support -- the wub "?!" 14:25, 4 December 2016 (UTC)[reply]
  21.   Support --β16 - (talk) 11:12, 5 December 2016 (UTC)[reply]
  22.   Support--Praveen:talk 13:00, 5 December 2016 (UTC)[reply]
  23.   Support--Theredmonkey (talk) 13:34, 5 December 2016 (UTC)[reply]
  24.   Neutral There have been some issues about accessibility with such media. I wish I could remember what those issues were, but they should be investigated before implementing this. --Tryptofish (talk) 00:18, 6 December 2016 (UTC)[reply]
  25.   Strong support We're missing a trick by not being able to integrate 3D files. Volupedia gives a nice idea of how it would look. Richard Nevell (WMUK) (talk) 10:46, 6 December 2016 (UTC)[reply]
  26.   Support This would be useful. --Vachovec1 (talk) 18:12, 6 December 2016 (UTC)[reply]
  27.   Support --Ανώνυμος Βικιπαιδιστής (talk) 21:20, 6 December 2016 (UTC)[reply]
  28.   Support -- Vuzorg (talk) 18:51, 7 December 2016 (UTC)[reply]
  29.   Support CFCF 💌 📧 20:58, 7 December 2016 (UTC)[reply]
  30.   Support This has been on the table for some time now. Daniel Case (talk) 05:39, 8 December 2016 (UTC)[reply]
  31.   Support--Alexmar983 (talk) 08:56, 8 December 2016 (UTC)[reply]
  32.   Support--Kilom691 (talk) 21:16, 8 December 2016 (UTC)[reply]
  33.   Support--Psychoslave (talk) 09:45, 9 December 2016 (UTC)[reply]
  34.   Support --Nikola (talk) 18:46, 9 December 2016 (UTC)[reply]
  35.   Support --Waldir (talk) 11:37, 10 December 2016 (UTC)[reply]
  36.   Support --OrsolyaVirág (talk) 13:14, 10 December 2016 (UTC)[reply]
  37.   Support --TanvirH (talk) 20:36, 10 December 2016 (UTC)[reply]
  38.   Support 4nn1l2 (talk) 22:43, 10 December 2016 (UTC)[reply]
  39.   Support - By rotation please.DPdH (talk) 12:06, 11 December 2016 (UTC)[reply]
  40.   Support  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:15, 11 December 2016 (UTC)[reply]
  41.   Support — NickK (talk) 13:35, 12 December 2016 (UTC)[reply]

360 panorama support

  • Problem: 360 Photos is a mainstream media type. Articles & MediaViewer doesn't support it.
  • Who would benefit: Readers and editors of wikis/Wikipedia technical articles, architecture and nature related article would benefit . Wikiversity learning resources, learning projects, and research will get benefit.

Community discussion

Note: As this proposal is over 360 panorama support, I've replaced the very misleading image with a panorama. Dispenser (talk) 01:09, 3 December 2016 (UTC)[reply]

Voting – 360 panorama support

  1.   Support--Shizhao (talk) 03:03, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 07:01, 28 November 2016 (UTC)[reply]
  3.   Support MichaelMaggs (talk) 20:19, 28 November 2016 (UTC)[reply]
  4.   Support --Jarekt (talk) 04:06, 30 November 2016 (UTC)[reply]
  5.   Support Ainali (talk) 16:00, 30 November 2016 (UTC)[reply]
  6.   Support -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  7.   Support --EugeneZelenko (talk) 18:08, 1 December 2016 (UTC)[reply]
  8.   Support — KPFC 💬 23:26, 1 December 2016 (UTC)[reply]
  9.   Support NMaia (talk) 01:39, 2 December 2016 (UTC)[reply]
  10.   Support Libcub (talk) 02:49, 2 December 2016 (UTC)[reply]
  11.   Support As per above, we need many more filetypes. —Justin (koavf)❤T☮C☺M☯ 03:54, 2 December 2016 (UTC)[reply]
  12.   Support Draceane (talk) 10:28, 2 December 2016 (UTC)[reply]
  13.   Support - Laurentius (talk) 13:43, 2 December 2016 (UTC)[reply]
  14.   Support--Sannita - not just another it.wiki sysop 13:51, 2 December 2016 (UTC)[reply]
  15.   Support --Framawiki (talk) 20:45, 2 December 2016 (UTC)[reply]
  16.   Support SamanthaNguyen (talk) 01:29, 3 December 2016 (UTC)[reply]
  17.   Strong support --jdx Re: 09:24, 3 December 2016 (UTC)[reply]
  18.   Support Jo-Jo Eumerus (talk, contributions) 09:31, 3 December 2016 (UTC)[reply]
  19.   Support MichaelSchoenitzer (talk) 10:19, 3 December 2016 (UTC)[reply]
  20.   Support – Susanna Ånäs (Susannaanas) (talk) 11:28, 3 December 2016 (UTC)[reply]
  21.   Support --Virginia Gentilini (talk) 13:07, 3 December 2016 (UTC)[reply]
  22.   Support --Yiyi (talk) 15:27, 3 December 2016 (UTC)