Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Multimedia

< Community Wishlist Survey 2016
(Redirected from 2016 Community Wishlist Survey/Categories/Multimedia)
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)[reply]
  23.   Support --Nevit (talk) 21:05, 3 December 2016 (UTC)[reply]
  24.   Support --By erdo can (talk) 14:16, 4 December 2016 (UTC)[reply]
  25.   Support -- the wub "?!" 14:26, 4 December 2016 (UTC)[reply]
  26.   Support --β16 - (talk) 11:12, 5 December 2016 (UTC)[reply]
  27.   Support--Praveen:talk 13:01, 5 December 2016 (UTC)[reply]
  28.   Support -- Wikimandia (talk) 19:55, 5 December 2016 (UTC)[reply]
  29.   Support --Tryptofish (talk) 00:20, 6 December 2016 (UTC)[reply]
  30.   Support That would be a really cool feature. Richard Nevell (WMUK) (talk) 10:43, 6 December 2016 (UTC)[reply]
  31.   Support--Ranjithsiji (talk) 11:12, 6 December 2016 (UTC)[reply]
  32.   Support Pabouk (talk) 13:07, 6 December 2016 (UTC)[reply]
  33.   Support --Vachovec1 (talk) 18:19, 6 December 2016 (UTC)[reply]
  34.   Support --Ανώνυμος Βικιπαιδιστής (talk) 21:22, 6 December 2016 (UTC)[reply]
  35.   Support--EftichiaKosma (talk) 7:51, 7 December 2016 (UTC)
  36.   Support -- Vuzorg (talk) 18:52, 7 December 2016 (UTC)[reply]
  37.   Support — Rhododendrites talk \\ 22:36, 7 December 2016 (UTC)[reply]
  38.   Support Daniel Case (talk) 05:36, 8 December 2016 (UTC)[reply]
  39.   Support --Psychoslave (talk) 09:46, 9 December 2016 (UTC)[reply]
  40.   Support --Arnd (talk) 13:44, 9 December 2016 (UTC)[reply]
  41.   Support --Spencer (talk) 14:38, 9 December 2016 (UTC)[reply]
  42.   Support --Nikola (talk) 18:46, 9 December 2016 (UTC)[reply]
  43.   Support-- --Ttzavaras (talk) 19:33, 9 December 2016 (UTC)[reply]
  44.   Support--Nizil Shah (talk) 06:49, 10 December 2016 (UTC)[reply]
  45.   Support →Spiritia 08:06, 10 December 2016 (UTC)[reply]
  46.   Support Georgy Palpurin ShareBulgaria team (talk) 08:37, 10 December 2016 (UTC)[reply]
  47.   Support --Waldir (talk) 11:39, 10 December 2016 (UTC)[reply]
  48.   Support —Ynhockey (talk) 16:00, 10 December 2016 (UTC)[reply]
  49.   Support --TanvirH (talk) 20:37, 10 December 2016 (UTC)[reply]
  50.   Support --NaBUru38 (talk)
  51.   Support 4nn1l2 (talk) 22:45, 10 December 2016 (UTC)[reply]
  52.   Support - DPdH (talk) 12:06, 11 December 2016 (UTC)[reply]
  53.   Support  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:15, 11 December 2016 (UTC)[reply]
  54.   Support It would be a great help to get this feature in order to move forward with c:Commons:Project to create spherical panoramas of important monuments --Poco a poco (talk) 20:59, 11 December 2016 (UTC)[reply]
  55.   Support --Soluvo (talk) 00:54, 12 December 2016 (UTC)[reply]
  56.   Support — NickK (talk) 13:36, 12 December 2016 (UTC)[reply]
  57.   Support--Mikheil Talk 21:19, 12 December 2016 (UTC)[reply]

Allow bulk uploads

  • Problem: Upload files page feels really outdated and it is really time consuming. The biggest problem is that it is limited to 50 files. Not having the capability to batch upload more files with ease is off putting for many users, including me. On another note, when copying text fields after the files are uploaded, seems that the script doing that is quite heavy on the browsers and it causes them to freeze up or crash often.
  • Who would benefit: Everybody that uploads files in bulk.
  • Proposed solution: Revamping the upload page, or providing desktop tools to do so. (Maybe FTP transfer, with readout from metadata?)
  • More comments: I've noticed that oftentimes when uploading 50 images per se, the upload process won't process one or two images. I need to remove them from queue, and then add them again to have them uploaded.

Community discussion

Petrovskyz What does this pertain to specifically ? The commons upload wizard page, the old style upload page, or certain other site specific upload pages ? —TheDJ (talk • contribs) 11:34, 12 November 2016 (UTC)[reply]

To add - the type of standalone tools you've described already exist: c:Commons:Upload tools#Standalone desktop applications -FASTILY 20:37, 13 November 2016 (UTC)[reply]
It mentions "50 files" and "copying text fields", so definitely UploadWizard. Special:Upload only allows uploading one file at a time. Matma Rex (talk) 23:49, 14 November 2016 (UTC)[reply]

Voting – Allow bulk uploads

  1.   Oppose per my comment above, and because excellent third party tools are available -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  2.   Oppose -<(kmk)>- (talk) 17:18, 5 December 2016 (UTC) Commons needs more quality images rather than more bulk.[reply]
  3.   Oppose One of the reasons I don't upload my own images in bulk is that I prefer to follow policy and write a descriptive filename instead of what the camera and the software assign. This also requires categorizing each image separately. Bulk uploaders don't do this ... we have way too many images that will take us years to properly categorize as they were uploaded with cryptic filenames and given one overbroad category, if at all. We need less of these, not more. Daniel Case (talk) 05:42, 8 December 2016 (UTC)[reply]

Increase file size limits

  • Problem: File size limits seem to be a bit outdated. Large panoramas, bigger video files (bear in mind, .ogg or .webM formats aren't nowhere near efficient, so files will be big).
  • Who would benefit: Everybody that uploads large files (videos for example).
  • Proposed solution:
  • More comments:
  • Phabricator tickets:

Community discussion

Voting – Increase file size limits

  1.   Neutral – 4GB is enough in my opinion. Guycn2 · ☎ 19:08, 29 November 2016 (UTC)[reply]
  2.   Oppose Dubious value, and at high developer cost (would have to migrate from swift to something else) -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  3.   Oppose Not an urgent priority. We'll have to do this eventually, but we can afford to kick the can down the road for a few years. MER-C (talk) 12:56, 1 December 2016 (UTC)[reply]
  4.   Neutral Not a huge priority. Doc James (talk · contribs · email) 04:03, 3 December 2016 (UTC)[reply]
  5.   Oppose 4GB is already much more than needed -- Aspiriniks (talk) 09:33, 4 December 2016 (UTC)[reply]
  6.   Oppose, 4GB is really enough for most reasonable uses. Of course we can imagine exceptional cases (e.g. uploading a video of Bernie Sanders filibuster), but it is really better to split such videos in several files, as downloading or playing a 4GB video is already difficult for many users — NickK (talk) 13:40, 12 December 2016 (UTC)[reply]

Allow variants of an image to be derived from a single SVG

  • Problem: Many vector images on Commons are identical except for a small change (example) leading to extra effort for illustrators to update a common feature. If they slip up, this leads to an inconsistent experience for the reader. One solution is to misuse the systemLanguage switch, as follows:
 
Generic image
 
As on the Tokyo Skytree article
 
As on the Canton Tower article
 
As on the CN Tower article
 
As on the Ostankino Tower article
 
As on the Oriental Pearl Tower article
 
As on the Milad Tower article
 
As on the KL Tower article
… but this is such an abominable hack!
  • Who would benefit: Illustrators (and readers)
  • Proposed solution: We could instead add a custom attribute to the switch tag similar to the systemLanguage one. The MediaWiki renderer will pick it up and render the correct thumbnail whereas other viewers simply ignore it.
  • Phabricator tickets:

Community discussion

Parametrized SVGs could be one approach (upload a template, replace parameters from URL or from image wikimarkup). DOM and templating do not go well together though. --Tgr (WMF) (talk) 04:46, 18 November 2016 (UTC)[reply]

This may be very helpful for maps too where a country or region should be highlighted. I think that a customisable css provided as parameter or from image wikimarkup may be the best solution. --Ikonact (talk) 12:36, 21 November 2016 (UTC)[reply]

The technical RfC SVG Upload should (optionally) allow the xhtml namespace is related to this proposal. There are some security and sandboxing challenges that need to be considered before we can allow arbitrary SVG markup constructs on wiki. Enabling the complete SVG specification is closely related to allowing arbitrary HTML which is not allowed for obvious reasons. --BDavis (WMF) (talk) 19:12, 22 November 2016 (UTC)[reply]

Thanks, I understand that arbitrary SVG markup constructs may lead to security issues. May be you can consider css parameters from image wikimarkup. If the svg is fix we could only modify the style of elements with given id.
As an example, in the picture above instead of using <switch><use xlink:href="#path4168-8" fill="#ff0000" systemLanguage="or"/></switch> inside the svg code we can call the image with File:tallest towers in the world.svg|path4168-8=fill:"#ff0000" or something similar. This will be limited only to style sheets and predefined svg elements and may avoid security issues.
Such a possibility will allow to create maps and highlight one or several countries or regions without uploading several files. Thanks --Ikonact (talk) 11:09, 23 November 2016 (UTC)[reply]
That's a good idea, @Ikonact:, though allowing arbitrary argument names may clash with existing or future use. We could instead use CSS classes e.g. File:image.svg|class=id1:class1 class2,id2:class3 gives <foo id="id1" class="class1 class2"/> ... <bar id="id2" class="class3"/>, overriding (or appending to?) any exisiting classes. (HTML 4 disallows "|" or "=" in id and class names.) Cheers, cmɢʟee⎆τaʟκ 23:00, 23 November 2016 (UTC)[reply]
Thanks Cmglee, you are right about the arbitrary argument names. I agree that fixed arguments will be better approach. The only limitation I see with your proposal is that one need to have predefined classes inside the svg to apply them to the selected elements. Like this we loose the flexibility to define any style that is not inside the svg. My suggestion will be to have the freedom to define the style in the wiki templates. e.g. File:image.svg|selector=id1:(fill:#ff0000; border-width: 2px;),class1:(display: none;) gives <foo id="id1" style="fill:#ff0000; border-width: 2px;"/> ... <bar id="id2" class="class1" style="display: none;"/>, overriding the style. But I am not sure if there are no security issues with css as urls can be linked... to be checked.--Ikonact (talk) 09:09, 24 November 2016 (UTC)[reply]

Voting – Allow variants of an image to be derived from a single SVG

  1.   Support--Shizhao (talk) 03:04, 28 November 2016 (UTC)[reply]
  2.   Support--Wesalius (talk) 07:01, 28 November 2016 (UTC)[reply]
  3.   Support--Aracali (talk) 14:59, 28 November 2016 (UTC)[reply]
  4.   Support Pamputt (talk) 07:41, 1 December 2016 (UTC)[reply]
  5.   Support --Tohaomg (talk) 15:34, 1 December 2016 (UTC)[reply]
  6.   Support -Flappiefh (talk) 17:52, 1 December 2016 (UTC)[reply]
  7.   Support NMaia (talk) 01:41, 2 December 2016 (UTC)[reply]
  8.   Support —Justin (koavf)❤T☮C☺M☯ 03:54, 2 December 2016 (UTC)[reply]
  9.   Support Draceane (talk) 10:28, 2 December 2016 (UTC)[reply]
  10.   Support --Ikonact (talk) 15:31, 2 December 2016 (UTC)[reply]
  11.   Support --LikeLifer (talk) 17:46, 3 December 2016 (UTC)[reply]
  12.   Support Railwayfan2005 (talk) 23:02, 3 December 2016 (UTC)[reply]
  13.   Support --β16 - (talk) 11:14, 5 December 2016 (UTC)[reply]
  14.   Support -<(kmk)>- (talk) 17:16, 5 December 2016 (UTC) reduces the threshold to achieve consistency across articles of a kind.[reply]
  15.   Support Andyrom75 (talk) 09:13, 6 December 2016 (UTC)[reply]
  16.   Support--Ranjithsiji (talk) 11:08, 6 December 2016 (UTC)[reply]
  17.   Support Pabouk (talk) 13:04, 6 December 2016 (UTC)[reply]
  18.   Support Is this technically feasible? Blue Rasberry (talk) 19:27, 6 December 2016 (UTC)[reply]
  19.   Support --Ανώνυμος Βικιπαιδιστής (talk) 21:11, 6 December 2016 (UTC)[reply]
  20.   Support--EftichiaKosma (talk) 7:51, 7 December 2016 (UTC)
  21.   Oppose -- SVG is an outside specification; it should not be butchered. SVG editors will not have support for such a feature, so it will be inaccessible to ordinary users. The hack will fail when WP serves SVG directly and lets the user's browser and acceptLanguage control. If browsers don't implement the extension, then everything disappears -- even the misuse of systemLanguage. Furthermore, rsvg currently has minimal to nonexistent support and does not do systemLanguage correctly now, so adding features is a pipe dream. The desired feature is a presentation issue; there are better ways to do it. Glrx (talk) 02:55, 9 December 2016 (UTC)[reply]
  22.   Oppose I oppose to the idea, that will broke open standard of SVG image format as it is in the proposed solution. If there are alternate solutions as in Communinty discussion, then it could be acceptable. --Snek01 (talk) 12:20, 9 December 2016 (UTC)[reply]
  23.   Neutral I'd support this if there was a way to download a "rendered" svg file with the specific highlight hardcoded, for external use. Otherwise it's not much use to have open licenses if we're putting barriers to reuse of the images. --Waldir (talk) 11:43, 10 December 2016 (UTC)[reply]
  24.   Support --TanvirH (talk) 20:37, 10 December 2016 (UTC)[reply]
  25.   Support --Plagiat (talk) 18:41, 11 December 2016 (UTC)[reply]
  26.   Support--David1010 (talk) 20:30, 11 December 2016 (UTC)[reply]
  27.   Support if feasible without damaging usability of a file — NickK (talk) 13:42, 12 December 2016 (UTC)[reply]

Apple Photos sharing extension for Commons

  • Problem: It takes several steps to upload images from Apple's Photos to Wikipedia commons. You first have to export each image in .jpg format, then upload them using the Commons uploader.
  • Who would benefit: Commons contributors who use MacOS Photos for image management
  • Proposed solution: Apple allows extensions to be added to Photos for direct sharing. Creating one for Commons should not be that hard. Maybe Apple might fund it.
  • Phabricator tickets:

Community discussion

As a Mac user myself, I'm skeptical that there are a significant enough number of contributors who use Photos to even warrant the time investment required to create such an extension. For now, there is a plethora of standalone upload tools which are up to the task -FASTILY 00:43, 21 November 2016 (UTC)[reply]

I didn't see anything on the list of upload tools the does what I want. Am I missing something?--ArnoldReinhold (talk) 02:12, 21 November 2016 (UTC)[reply]

Industrial standards have evolved for a long time now. If one decides not to use standards or software handling standrd data formats, it's his own decision. BJ Axel (talk) 08:16, 2 December 2016 (UTC)[reply]

Voting – Apple Photos sharing extension for Commons

  1.   Oppose per my comment above. Provides dubious value at high developer cost -FASTILY 02:16, 1 December 2016 (UTC)[reply]
  2.   Oppose per Fastily. MER-C (talk) 12:54, 1 December 2016 (UTC)[reply]
  3.   Oppose per my comment. — The preceding unsigned comment was added by BJ Axel (talk)
  4.   Oppose --Ilya (talk) 02:33, 7 December 2016 (UTC)[reply]

Computer vision

  • Problem: Currently Labs has no GPUs clusters to support TensorFlow, a open source machine learning system.
  • Who would benefit: Commons/Image search, the image classification system is even able to generator alt text
  • Proposed solution: Add a server with at least an NVIDIA Tesla K20 GPU. Expect cost is around $10,000
  • Phabricator tickets:
  • Proposer: Dispenser (talk) 16:26, 17 November 2016 (UTC)[reply]

Community discussion

I don't understand the problem. What are the tools that use TensorFlow, that are not fast enough? The only AI tool I know is the ORES extension. Maybe a cheaper solution in terms of maintenance costs would be to just allocate more CPUs. Also TensorFlow would require CUDA to run on NVIDIA graphic cards which is not open source at all and usually messy to set up in a linux environment.--Debenben (talk) 01:08, 20 November 2016 (UTC)[reply]
@Dispenser: Could you elaborate on what this would be used for? Ryan Kaldari (WMF) (talk) 18:54, 22 November 2016 (UTC)[reply]
I'm still trying to set it up, but from what I've read, TensorFlow basically is an out of the box image classification system now. According to the documentation, running it on CPUs is about 10x slower and the initial training time is 2 weeks on a Nvidia Tesla K20m (2012 GPU, ~$1000 used). It may be able to automate image categorization on commons (previous effort by User:DrTrigon). Dispenser (talk) 19:49, 22 November 2016 (UTC)[reply]
Depending on how you use deep learning running on CPU's is either a valid option or not. With transfer learning/retraining you can use tensorflow on an average CPU in under an hour with good results. If you want to train convolutional neural networks from scratch everything becomes a bit more complicated and using GPU's is adviced. On 2016_Community_Wishlist_Survey/Categories/Commons#Use_computer_vision_to_propose_categories using computer vision is discussed, I also show a small example per the easy method above. Let us first try to touch on using those methods on Wikimedia (Commons) and when we run into the hardware issues by that time discuss them. Currently there are many issues to tackle before we run into the hardware issues. Basvb (talk) 15:57, 29 November 2016 (UTC)[reply]

Voting – Computer vision

Crowdsourcing handles to Wikimedia Commons content

  • Problem: It is difficult for the Wikipedia reader or person browsing Wikimedia Commons to interact with or enrich an image or its metadata.
  • Who would benefit: All contributors to Wikimedia Commons content.
  • Proposed solution: There should be a framework for commenting, accessing tools such as positioning the image on a map, rectifying a map, annotating the image, identifying people or objects etc. These actions should be accessible from the Media Viewer, and if possible, already from the Wikipedia page. It is a complex problem, but solving the architecture should be started.
  • Clarification: The idea is to create a linking mechanism to tools, rather than create the tools, and work with the interface issues around it.
Example: A map exists in Wikimedia Commons. I would like to be able see a button in the MediaViewer for georeferencing it, or a button for annotating it, or a button for a zoomable viewer, or a button for geolocating an image. Alternatively, key actions could be accessed from the Wikipedia page. How could the actions be presented to the user? (Modified 17:37, 23 November 2016 (UTC))
  • Phabricator tickets: I will look for existing threads.

Community discussion

This is not an actionable proposal but a bunch of ideas. —TheDJ (talk • contribs) 15:48, 20 November 2016 (UTC)[reply]
@Susannaanas: This needs to be narrowed to a more specific proposal. Please choose a specific feature that you would like to have added to the Media Viewer so that it is clear what supporters will be voting for. Ryan Kaldari (WMF) (talk) 18:12, 21 November 2016 (UTC)[reply]

Voting – Crowdsourcing handles to Wikimedia Commons content

no votes
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Multimedia&oldid=24960909"