Community Wishlist Survey 2021/Multimedia and Commons

Multimedia and Commons
31 proposals, 399 contributors, 915 support votes
The survey has closed. Thanks for your participation :)



Add wikitext description pages for Commons tabular data files

Edit proposal/discussion

  • Problem: Commons .tab and .map files cannot have categories, nor be described in wikitext, nor be described in structured data.
    Without descriptions or categories, the files aren't readily discoverable. It is not even currently possible to document what particular rows, or columns, or cells represent. Nor is it possible to describe properly where the data has come from, or any issues with it.
  • Who would benefit: The Commons tabular-data space is available to store tabular-data files up to 2Mb in size. Such files might represent eg the raw data shown on a graph (but in an reusable, examinable form), or important data series about the real world. But at the moment usability is crippled, because the files aren't describable or discoverable. As a result the potential is not used. Also sometimes people instead try to write large time-series into Wikidata items, for which they are utterly unsuited, causing difficulties and unfortunate item bloat on Wikidata. If our aim is making available the sum of human knowledge for every single human being to share, at the moment we are utterly failing to do that for tabular data.
  • Proposed solution: Attach a regular wikitext page to each tabular-data file, in the way we do for image files, to allow wikitext descriptions and categorisations of the files. Ideally also include a structured data slot, to allow the file metadata can be described and queried for using structured statements.
  • More comments: Ideally the description pages would act just like regular Commons pages. As a second-best it's also been suggested to add description pages as subpages (cf the '/doc' subpages used for templates), if that would be easier.
  • Phabricator tickets: T155290, T249896, T242596, T235332, T250919
  • Proposer: Jheald (talk) 19:22, 17 November 2020 (UTC)[]

Discussion

  • Huh, I didn't realize these were in a separate "Data" namespace, rather than under "File". I realize data files don't display readily as images, is that the reason for the distinction? In any case, aside from display, I can't think of any good reason for treating data files so differently from image files, they should have most of the same metadata fields for example. ArthurPSmith (talk) 16:20, 18 November 2020 (UTC)[]
  • "Nor is it possible to describe properly where the data has come from, or any issues with it." There is a description, license and a sourcing field in the format for each. I agree it isn't easy to use, but when people read the help pages (which they need to do anyways, to even begin to understand how to use these spaces), then these fields are documented. I'd say we should not confuse ability to document things with people's motivation/desire to actually do so in practice, which i find just as, if not even more likely to be the problem. —TheDJ (talkcontribs) 15:15, 2 December 2020 (UTC)[]
  • I'd love for c:Category:Tabular data of COVID-19 cases to contain actual data tables instead of their talk pages. Even better if those data tables' action=view presentations could include visualizations via /doc pages, similar to what we're currently using c:Data talk:COVID-19 cases in Santa Clara County, California.tab and c:COVID-19 pandemic in the San Francisco Bay Area#Santa Clara County for. – Minh Nguyễn 💬 08:14, 9 December 2020 (UTC)[]

Voting

  •   Support * Pppery * it has begun 02:07, 9 December 2020 (UTC)[]
  •   Support – Minh Nguyễn 💬 07:52, 9 December 2020 (UTC)[]
  •   Support NMaia (talk) 12:44, 9 December 2020 (UTC)[]
  •   Supportputnik 19:07, 9 December 2020 (UTC)[]
  •   Support Ciao • Bestoernesto 03:19, 10 December 2020 (UTC)[]
  •   Support TohaomgTohaomg (talk) 11:27, 10 December 2020 (UTC)[]
  •   Support Libcub (talk) 20:00, 10 December 2020 (UTC)[]
  •   Support Oh, DrPizza! (talk) 08:22, 12 December 2020 (UTC)[]
  •   Support Yeah, this is just way-broken right now. That said, I have seen techniques (e.g. in people's JS and CSS pages) for escaping stuff and making it MW content, e.g. to add categories, or apply w:en:Template:Italic_title, etc., so maybe there's a way to do that with these pages already (perhaps variable on a per-format basis)? Still, it would be better to just have a wiki "frame" around the actual content file.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:35, 15 December 2020 (UTC)[]
  •   Support β16 - (talk) 09:31, 15 December 2020 (UTC)[]
  •   Support, maybe the bug that limits the max file-size to ~500MB could be fixed at the same time? PinkPanda272 (talk) 08:26, 16 December 2020 (UTC)[]
  •   Support Michael Childs (talk) 01:43, 17 December 2020 (UTC)[]
  •   Support Jklamo (talk) 15:48, 19 December 2020 (UTC)[]
  •   Support 5910 C (talk) 21:42, 19 December 2020 (UTC)[]
  •   Support Nachtbold (talk) 17:19, 21 December 2020 (UTC)[]

Illustrations should show the current season

Edit proposal/discussion

  • Problem: Illustrations / photos in the articles should reflect the current season
  • Who would benefit: the users of the encyclopedia
  • Proposed solution: A field for an illustration / photo should be able to be stored with several images so that the appropriate image is automatically shown according to the season: in winter the Vogelsberg in snow or in summer in green
  • Other comments:
  • Phabricator tickets:
  • Proposer: Neptuul (talk) 16:55, 21 November 2020 (UTC)[]

Discussion

  • Can be an option (including Global option).--BoldLuis (talk) 17:52, 11 December 2020 (UTC)[]
  • Make it based on localisation. Reason- seasons are different between Northern and Southern hemispheres. Some places at equator have no "seasons" so they can ignore. CaribDigita (talk) 06:46, 14 December 2020 (UTC)[]

Voting

  •   Support Movses (talk) 19:23, 8 December 2020 (UTC)[]
  •   Oppose This is an intriguing idea, but the encyclopedic record of a place should reflect how it appears in all seasons, so I'm not sure it's something that'd be desirable. And even if it is, it's not something we'd need developer help to accomplish, as we already have templates/magic words that can detect the time and date and display different material accordingly. {{u|Sdkb}}talk 09:42, 9 December 2020 (UTC)[]
  •   Support Ciao • Bestoernesto 03:21, 10 December 2020 (UTC)[]
  •   Support MarioSuperstar77 (talk) 13:27, 11 December 2020 (UTC)[]
  •   Support BoldLuis (talk) 17:52, 11 December 2020 (UTC)[]
  •   Neutral if it's adaptable to the user's position on Earth. Golmore (talk) 07:02, 18 December 2020 (UTC)[]
  •   Support Sounds good! Nadzik (talk) 11:49, 19 December 2020 (UTC)[]
  •   OpposeOmegatron (talk) 15:20, 20 December 2020 (UTC)[]
  •   Oppose Just adds confusion. "Hey, this URL's beech looks great!", "what? I see only snow" --Wotheina (talk) 05:37, 21 December 2020 (UTC)[]
  •   Oppose Nachtbold (talk) 17:12, 21 December 2020 (UTC)[]
  •   Oppose Basically, the idea could be good if we had good photos for all seasons. We should first of all choose the best and most representative photo. In a lot of places, snow doesn't fall every year and it would be weird to assert a default image that rarely represents the subject. To be honest, this raises even more problems for small gain. However, I still haven't done it (so I'll try to do it today): it would simply be necessary to ask to add the property winter view (P5252) to the infobox. — Baidax 💬 17:33, 21 December 2020 (UTC)[]

Option to load SVG instead of PNG on pages by default

Edit proposal/discussion

  • Problem: All SVG content is converted to PNG before sent to public.
  • Who would benefit: Servers, readers, and basically anyone.
  • Proposed solution: Load SVGs instead of PNGs on content pages (and file pages by default)
  • More comments: I'm proposing this so as to load SVG content natively (i.e. SVG directly delivered to content) instead of backend renders. Browsers have long been natively supporting SVG content, so it seems weird that vectors are still converted to raster graphics when web browsers genuinely support SVG already for a long time. It can be enabled as default on PC clients before introducing it to mobile though, considering even the lowest end PCs are able to load SVGs in browsers natively, but cannot confirm the state of it in mobile phones. Also, it helps in cases of Math functions where wikicode is transcluded to SVG before transcluding again to PNG content.
  • Phabricator tickets:
  • Proposer: 1233 T / C 18:37, 19 November 2020 (UTC)[]

Discussion

  • I think this would be an improvement overall, but this would also result in some issues for a small but non-zero number of SVG images that rely on librsvg quirks and would render differently if loaded directly. Jc86035 (talk) 09:57, 22 November 2020 (UTC)[]
    • @Jc86035: I think that this can be fixed, but not a very large problem. It should be a minor issue but not affecting a lot of things. The loader can also request a PNG version if it is using librsvg quirks (i.e. exemptions).--1233 T / C 10:20, 22 November 2020 (UTC)[]
      • Please see the discussion on serving/not-serving SVGs (mainly for missing reliable SVG sanitizer) at phabricator.wikimedia.org/T40010#6637830 --Volker E. (WMF) (talk) 18:31, 29 November 2020 (UTC)[]
        • Interesting question, but I'm curious if this is what this wishlist hope : if passed, the team would need to develop a reliable SVG sanitizer then.--1233 T / C 05:54, 30 November 2020 (UTC)[]
Some infos about santizing: https://github.com/scour-project/scour/issues/254#issue-632703337  — Johannes Kalliauer - Talk | Contributions 06:26, 9 December 2020 (UTC)[]

With showing SVG files directly, comes the power of SVG animations (SMIL). Comparing SMIL to gif animations is like comparing SVG to PNG or JPEG formats (though Internet Explorer does not support SVG animations). Also it seems that Wikimedia does not support some SVG features like text along path (see the first image) or has problem showing patterns (See the second image). So I think showing SVG files directly would be a good thing.

@JoKalliauer:

  • Could you please provide some examples of different rendering on different browsers?
  • SVGs can be edited to change the fonts (for example to some web-safe font). Also Wikimedia fonts are not comprehensive enough (for example there is not a single Persian font installed)
  • Do all SVG files have longer client-rendering time? I don't think it will be noticeable even for a medium-sized vector.

What percentage of SVGs are 25- and 95-megabyte files? The particular images you mentioned have almost no usage on Wikipedia. Jooja (talk) 18:48, 11 December 2020 (UTC)[]

 
librsvg-rendering of one the view featured svgs
 
Rendering by most browsers

@Jooja:

 — Johannes Kalliauer - Talk | Contributions 19:53, 11 December 2020 (UTC)[]

@Jooja: Your examples are the best example to show, as long as you know the renderer the bugs can be fixed (both are fixed), but without knowing the renderer the rendering is unpredictable and bugs can't be fixed.  — Johannes Kalliauer - Talk | Contributions 21:21, 11 December 2020 (UTC)[]

I hadn't seen this page which is for resvg library. It seems a good comparison table for SVG support in some browsers and libraries (including librsvg). Jooja (talk) 10:57, 12 December 2020 (UTC)[]

@Jooja: I would also prefer resvg (by @RazrFalcon:), it is imho maybe the most promising svg2png-libary, in terms of supported features and especially for speed. Since it is optimized for speed, maybe an additional png-optimizer for WikiMedia might make sense to reduce file-size (reduces ~10%), but that's no problem. However animated SVGs will be rendered as a static png-image, but native animated svgs are imho also not considered as a web-save-option, so there exist imho no workable solution for animated SVGs.  — Johannes Kalliauer - Talk | Contributions 15:44, 12 December 2020 (UTC)[]

@Ralf Roletschek: Special:Diff/20821104

  • German(Deutsch): Wenn man ein SVG-Bild als PNG braucht, dann soll das der Nutzer selbst konvertieren. Kann man online machen, kann man mit Freeware machen,... Außerdem ein Vektorbild als Rasterbild zu bearbeiten ist genauso sinnvoll ein Qualitätsbild mit Fujifilm X-M1 mit einer Auflösung von 200px x 150px aufzunehmen.
  • English: If someone wants a SVG as PNG, than it's the users issue. It can be done online or per Freeware. Converting SVG2PNG is as intelligent as having the best camera and saving the image which a resolution of 200px x 150px.

 — Johannes Kalliauer - Talk | Contributions 08:22, 17 December 2020 (UTC)[]

SVG ist in der wahren Welt da draußen nahezu unbekannt und unbrauchbar. Es ist wertlos für Nachnutzer, deshalb sollten wir denen wenigstens PNG anbieten. Ist zwar ebenso wenig verbreitet, kann aber wenigstens fast immer gelesen werden. --Ralf Roletschek (talk) 10:18, 17 December 2020 (UTC)[]

Voting

  •   Support 4nn1l2 (talk) 18:12, 8 December 2020 (UTC)[]
  •   Support AinScept (talk) 18:38, 8 December 2020 (UTC)[]
  •   Support IagoQnsi (talk) 18:43, 8 December 2020 (UTC)[]
  •   Support Silver hr (talk) 21:48, 8 December 2020 (UTC)[]
  •   Support Martinkunev (talk) 23:18, 8 December 2020 (UTC)[]
  •   Support Languageseeker (talk) 01:05, 9 December 2020 (UTC)[]
  •   Support Alkari (talk) 01:12, 9 December 2020 (UTC)[]
  •   Support PianistHere (talk) 01:46, 9 December 2020 (UTC)[]
  •   Support Shizhao (talk) 03:01, 9 December 2020 (UTC)[]
  •   Support Петър Петров (talk) 17:46, 9 December 2020 (UTC)[]
  •   Support MichaelSchoenitzer (talk) 19:34, 9 December 2020 (UTC)[]
  •   Support Globbet (talk) 22:25, 9 December 2020 (UTC)[]
  •   Support - Darwin Ahoy! 01:18, 10 December 2020 (UTC)[]
  • if for all svg-files:   Oppose, because Bugs will increase, due to unpredicted Rendering of individual browser-rendering, see eg. 1, 2, 3, 4 (all of them are from the 124 Featured svg-pictures)  — Johannes Kalliauer - Talk | Contributions 11:07, 10 December 2020 (UTC)[]
  •   Support Jooja (talk) 16:08, 10 December 2020 (UTC)[]
  •   Support Likibp (talk) 13:56, 11 December 2020 (UTC)[]
  •   Support Arnd (talk) 16:58, 11 December 2020 (UTC)[]
  •   Support BoldLuis (talk) 17:51, 11 December 2020 (UTC)[]
  •   Support DemonDays64 (talk) 18:37, 11 December 2020 (UTC)[]
  •   Support My endorsement as it allows svg animation. As for the problem pointed out by @JoKalliauer:, we can set the default display format to png and add an option to display in original svg for those animated ones.IamCristYe (talk) 12:56, 12 December 2020 (UTC)[]
  •   Support Francois-Pier (talk) 22:46, 12 December 2020 (UTC)[]
  •   Support Makendo k (talk) 00:46, 13 December 2020 (UTC)[]
  •   Support The Blinder Grunt (talk) 07:56, 13 December 2020 (UTC)[]
  •   Support Dinock90 (talk) 09:41, 13 December 2020 (UTC)[]
  •   Support Izno (talk) 20:05, 13 December 2020 (UTC)[]
  •   Support Boehm (talk) 17:10, 14 December 2020 (UTC)[]
  •   Support Pinage404 (talk) 22:40, 14 December 2020 (UTC)[]
  •   Oppose Nachnutzer brauchen die PNG --Ralf Roletschek (talk) 18:54, 15 December 2020 (UTC)[]
  •   Support Lt2818 (talk) 03:00, 17 December 2020 (UTC)[]
  •   Support G.prof (talk) 15:59, 17 December 2020 (UTC)[]
  •   Support Gustmd7410 (talk) 17:47, 19 December 2020 (UTC)[]
  •   Support Modern browsers do a far better job of rendering svg than the svg->png converter used at Commons. Uanfala (talk) 23:50, 20 December 2020 (UTC)[]
  •   Support David1010 (talk) 13:29, 21 December 2020 (UTC)[]
  •   Support S8321414 (talk) 14:31, 21 December 2020 (UTC)[]
  •   Oppose Nachtbold (talk) 17:17, 21 December 2020 (UTC)[]

Audio file player

Edit proposal/discussion

Polski: Odtwarzacz plików audio

  • Problem: Obsolete video player that supports audio
  • Who would benefit: Everyone listening to audio files
  • Proposed solution: Replace the current player with a simpler one used in html-5, or create a new one
  • Phabricator tickets:
  • Proposer: Borys Kozielski (talk) 15:19, 17 November 2020 (UTC)[]

Discussion

Świetny pomysł. Najlepiej by było gdy to był odtwarzacz wielofunkcyjny dobrze dostosowany do każdej możliwości. Marek Mazurkiewicz (talk) 15:35, 17 November 2020 (UTC)pa fajnie jakby miał listy odtwarzania i zmianę prędkości odtwarzanania. Marek Mazurkiewicz (talk) 15:37, 17 November 2020 (UTC)[]

  • Z pewnością należy ulepszyć istniejące narzędzie. Mocno popieram propozycję! CelStrzel (talk) 18:43, 17 November 2020 (UTC)[]
  • @Borys Kozielski: Widziałeś nowy odtwarzacz wideo/audio? Dostępny w Preferencjach jako funkcja eksperymentalna. Może takie coś Ci pasuje? tufor (talk) 20:20, 23 November 2020 (UTC)[]
  • @Tufor: Nie, dziękuję za podpowiedź. Sprawdziłem i niestety porażka. To nie jest odtwarzacz audio/wideo tylko wyłącznie wideo. Wprawdzie odtwarza audio, ale w oknie z wideo, czyli w przypadku nagrań wyłącznie audio wyświetlana jest czarna plansza Borys Kozielski (talk) 15:42, 27 November 2020 (UTC)[]

Is this necessarily different from "Inline Audio-Player for pronunciations and other usages"? --Joalbertine (talk) 18:18, 19 December 2020 (UTC)[]

Voting

See Exif without restoring file

Edit proposal/discussion

  • Problem: Exif plays an important role in copyvio detection. Many files get deleted because of their Exif, especially on Commons. Sometimes an admin needs to check the Exif of an already deleted file (example). The solution to this problem is temporarily restoring the file or downloading the file and checking its metadata offline. It would be good for admins to be able to see Exif of deleted files without restoring or downloading them.
  • Who would benefit: Admins, especially Commons admins
  • Proposed solution: Add an ability to MediaWiki to see metadata of deleted files without restoring them
  • More comments:
  • Phabricator tickets:
  • Proposer: 4nn1l2 (talk) 21:15, 23 November 2020 (UTC)[]

Discussion

SDoC is not accessible and also not the entire EXIFs are in SDoC. Christian Ferrer (talk) 18:36, 8 December 2020 (UTC)[]

Voting

Image inheritance, a bequest safe for Wikimedia Commons

Edit proposal/discussion

  • Problem: Thousands of my pictures – probably millions of images from other Wikimedians – would be lost because they can currently(!) not be publicly published. We Wikimedians who are alive today can't upload the images if we're no longer alive, when these images in the future no longer restricted by copyright.
Deutsch: ("Tausende Bilder von mir - wahrscheinlich Millionen Bilder von anderen Wikipedianern werden verloren gehen, weil sie aktuell(!) nicht veröffentlicht werden dürfen und wir heute lebenden Wikipedianer nicht mehr leben werden und also die Bilder nicht mehr hochladen können, wenn sie in Zukunft keinen Einschräkungen mehr unterliegen werden.")
  • Who would benefit: Wikimedia Commons and all its users.
Deutsch: ("Wikimedia Commons und all seinen Benutzer*innen")
  • Proposed solution: I would like to be able to upload photos to a "private" – with a, to the normal ID, unrelated password – and extra protected user space. I'm thinking of interior photos, information boards, texts and so on. These photos are currently not covered by the Freedom of Panorama and must immediately be deleted. I would like to upload these photos "today", but save them for "later" (my digital "bequest", my "photo inheritance" for Wikimedia Commons).

    The way I envision it is that these files would 100 years after the uploading automatically be made free. Until then, they would just be available for administrators and myself. At the same would I already put these images "hidden" in the "proper" categories – but not available to non-administrators!

    Perhaps a cooperation with the Internet Archive would be useful here.

Deutsch: ("Sehr gern würde ich Fotos in einen „privaten“ - mit einem von der „normalen“ Kennung unabhängigen Passwort – und extra geschützten Benutzer-Bereich hochladen. Ich denke dabei zum Beispiel an Fotos von Innenräumen, Informationstafeln, Texten usw. Diese Fotos unterliegen aktuell nicht der Panoramafreiheit und müssten sofort gelöscht werden. Ich möchte diese Fotos aber „heute“ für „später“ hochladen (mein digitales „Vermächtnis“ / mein „Bild-Erbe“ für Wikimedia Commons ).

Meine Vorstellung ist, dass diese Aufnahmen etwa 100 Jahre nach dem Hochladen automatisch frei geschaltet werden. Bis dahin wären sie nur für Administratoren und mich selbst sichtbar. Gleichzeitig würde ich die Bilder schon „versteckt“ in die „richtigen“ Kategorie einfügen wollen - für Nicht-Administratoren unsichtbar!")

Vielleicht wäre hierbei eine Zusammenarbeit mit dem Internet Archive sinnvoll.

  • More comments:
See also: Community Wishlist Survey 2019/Multimedia and Commons/Image inheritance, a bequest safe for Wikimedia Commons
Since 2015 is there a Phabricator ticket that's touching the same area. I have the impression that only little progress have been made for that project.
Deutsch: ("Es gib seit 2015 einen Phabricator ( phab:T120454 ), der dem nahe kommt. Ich habe aber den Eindruck, dass das Projekt nur wenig voran kommt.")

Discussion

  • A good idea, but I would like to add one more point: I lost tens of thousands of pictures a few years ago when I lost a hard drive. Now, in order to prevent something like this in the future, I would like to upload images to Commons, then edit them there over time and move them to public space. I would also like to allow other people, if they were faster than me, to edit these images, categorize them, etc. So a semi-public space would be needed in which you can temporarily store large amounts of images for a longer period of time, once you're done made for general use. -- Marcus Cyron (talk) 19:29, 16 November 2020 (UTC)[]
    • That would be also very useful. I have, for example, about 25 000 photos on my HDD that are perfectly within the scope of Commons. Although I don't really care about image descriptions, categories and geolocating, I'm able to upload roughly as much as 2000 images a year (using Pattypan), but I take at least same number within the same period. So the Marcus Cyron's proposal would probably also help me a lot. — Draceane talkcontrib. 16:03, 27 November 2020 (UTC)[]
  • I think this is a cool idea, but I don't think it is the right size for CommTech to handle it, and I'm not strictly certain it should be in WMF's scope at all. Perhaps it is something which could be proposed to Internet Archive. --Izno (talk) 22:10, 16 November 2020 (UTC)[]
  • I wonder whether some kind of collaboration with Flickr would be good for this. — Bilorv (talk) 19:43, 17 November 2020 (UTC)[]
  • Exactly my thought. Currently this can only be done by uploading, deleting and categorising as Undelete in XXXX, but this method is prone to vandalism. Who knows if someone might remove the cats without notice?
It may not have to be part of commons. It could be a separate project maybe, since commons requires everything to be freely licensed. FOP issues, photos of posters etc. can definitely benefit from this new project for the future generations to see our world.--RZuo (talk) 21:16, 17 November 2020 (UTC)[]
  • Very much needed. Ideally the tool would allow us to edit pictures metadata (title/description/depictions) even if the picture is not publicly viewable yet. If it is judged to be fair use, a very small thumbnail could also be helpful to get an idea of the picture's potential. File information such as file size, type, and hopefully a measure of the image's grain/fineness should be publicly viewable. Having this metadata would for instance allow us to make sure we have completely covered a modern art painter's paintings. Syced (talk) 13:46, 18 November 2020 (UTC)[]
  • Agree, This is a very desired storage idea for files (contemp art) that might become PD in just a few years, but might get lost due to local hardware changes in between. Pelikana (talk) 15:28, 20 November 2020 (UTC)[]
  • Has been proposed many times, and although it's a nice idea there are difficult legal problems. The reason that some personal photographs can't be uploaded is that the photographer is not the sole copyright owner: the creator of some artistic thing being photographed (for example the architect of a building, the sculptor of a statue, or the graphic designer of a product label) is a joint owner of the copyright in the image. Without their consent the photographer can't upload the image, and the WMF can't host it, without risking third party copyright infringement (the details vary by country). Unfortunately the same restrictions still apply even if the repository is kept private for years until the third party copyrights expire: the mere act of storage itself requires the consent of all the copyright owners. And the WMF as provider of such a service could potentially be held in breach of third party rights under US law, even if the repository were hosted elsewhere. The idea may not be totally out of the question if some clever legal exemptions can be found, but so far the Foundation has shied away from it. MichaelMaggs (talk) 17:24, 20 November 2020 (UTC)[]
  • An alternative solution, for potential FoP issues, is to upload them knowingly, then to detete the images and to categorize its in the relevant FOP categories (or "Undele in 2080", ect...), so if a country change their law the images can be found and undeleted. Issue: we have already a big DR backlog. Christian Ferrer (talk) 19:01, 20 November 2020 (UTC)[]
  • Admins can undelete deleted images and tracking categories containing DRs (and even individual file pages) exist: c:Category:Undelete in 2021, c:Category:Undelete in 2022, c:Category:Undelete in 2050 etc. This doesn’t address the main issue and per se doesn’t mean copyrighted files should be uploaded now to be immediately deleted and undeleted some day, but might be good news for some of the commenters above. Tuvalkin (talk) 21:40, 11 December 2020 (UTC)[]
  • I agree with Christian Ferrer above. Every country has its own FOP laws like: only building's exteriors, interiors too, 2D or 3D art as well, only work of artists/architects who died at least 70 years ago, artists still alive and so on. The uploader could choose amongst a multitude of options like Statue, Painting, Legal Graffiti, Building Interior/Exterior, probable year of copyright expiration, Nation... When all the conditions are met in the future or when a country's FOP or Copyright law changes, then the images with the right flags could be undeleted. From a technical/programming point of view it can be done. From a legal point of view, I don't know! ... GiorgioGaleotti 18:33, 19 December 2020 (UTC)[]


Voting

  •   Support No doubt there are many hooks and eyes, but this proposal deserves to be continued. JopkeB (talk) 05:12, 9 December 2020 (UTC)[]
  •   Support Ciao • Bestoernesto 02:48, 10 December 2020 (UTC)[]
  •   Support JPxG (talk) 06:02, 10 December 2020 (UTC)[]
  •   Support Piensaimnieks (talk) 12:49, 10 December 2020 (UTC)[]
  •   Support MarioSuperstar77 (talk) 13:31, 11 December 2020 (UTC)[]
  •   Support --Aristeas (talk) 16:30, 11 December 2020 (UTC)[]
  •   Support Szalax (talk) 17:09, 11 December 2020 (UTC)[]
  •   Support BoldLuis (talk) 17:47, 11 December 2020 (UTC)[]
  •   Support The Blinder Grunt (talk) 07:56, 13 December 2020 (UTC)[]
  •   Support Dinock90 (talk) 09:30, 13 December 2020 (UTC)[]
  •   Support — Draceane talkcontrib. 13:23, 15 December 2020 (UTC)[]
  •   Support, with a twist. My own photo stack is 99% raw. Right now, Commons won't host proprietary Sony or Canon formats. Dead end? probably. But, maybe, there is some workaround possible. Retired electrician (talk) 18:55, 15 December 2020 (UTC)[]
  •   Support Monirec (talk) 11:12, 16 December 2020 (UTC)[]
  •   Strong support GiorgioGaleotti 17:50, 19 December 2020 (UTC)[]
  •   Support Would like to have this problem resolved. I am not sure about the best solution for this. Papuass (talk) 16:01, 21 December 2020 (UTC)[]
  •   Support Nachtbold (talk) 17:22, 21 December 2020 (UTC)[]

SVG to PNG converter that actually works

Edit proposal/discussion

  • Problem: Current SVG to PNG conversion is buggy, many images that work in Inkscape and major browsers are broken upon conversion on Commons. Blurs are cropped most of the time, clones behave unpredictably, hatch fills work on some resolutions and don't on others. The conversion library, librsvg, is no more being developed.
  • Who would benefit: Creators of highly-desirable high-quality SVG media
  • Proposed solution: Use Inkscape in batch mode for conversion on wikimedia servers - at least for files created in Inkscape, or per uploader's choice. How do browsers render SVG graphics, can their library be used for svg to png conversion?
  • More comments:
  • Phabricator tickets: phab:T243893 phab:T40010 phab:T193352
  • Proposer: Ponor (talk) 04:33, 17 November 2020 (UTC)[]

Discussion

  • Yeah not being able to use stuff like textpaths -- which work on every browser MDN lists -- really is annoying. This really doesn't seem like it would be that hard to implement at all, too. DemonDays64 (talk) 09:10, 17 November 2020 (UTC)[]
    @Ponor: Every complex software will have some software bugs. How to define "actually works"? If someone worked on this proposal, when to call work finished by which objective criteria? In my personal opinions this proposal is currently not discrete and well-defined. --AKlapper (WMF) (talk) 14:00, 17 November 2020 (UTC)[]
    @AKlapper (WMF):No one uses librsvg to make SVG images, but some (or most?) use Inkscape. So if I made my SVG in it, and it worked fine for me in Firefox and Chrome, I'd expect it to work on WP - but it often doesn't, and I need to go back to Inkscape, unlink all my clones, remove all my blurs, and make guesses what else might be "wrong" (nothing's wrong, the library is wrong). I was lucky to find this tool Commons_SVG_Checker so at least I didn't have to beg for speedy deletions of my uploads-gone-wrong. You'll say there are other users who do not use Inkscape. And that's fine, they'll still be able to use the abandoned library for svg2png conversion. Ponor (talk) 14:23, 17 November 2020 (UTC)[]
    Forgot to answer your question: call the work finished when we're using the newest stable version of Inkscape to do svg2png conversion (for Inkscape-generated SVGs at least)
  • Since all browsers (that WMF supports) support SVG now, why are we not serving SVG images instead? :) (I can see a case for 'it's a really large SVG don't want to DOS the servers, but that's something that can be worked around with some upper limit.) --Izno (talk) 18:38, 17 November 2020 (UTC)[]
    That said, there was a Phab discussion for switching the renderer at phab:T40010. Do consider. --Izno (talk) 18:45, 17 November 2020 (UTC)[]
    This is the best solution imo. svg -> png is clearly messy/error-prone and all major browser vendors have supported svg natively for years now. -FASTILY 04:55, 18 November 2020 (UTC)[]
    There is at least one other caveat (abuse like background-URL hacks) but these are things that can probably be worked around. --Izno (talk) 05:09, 18 November 2020 (UTC)[]
librsvg is actively developed [1], it is still the most common SVG-Renderer on Linux, most common bugs on commons are already fixed, the problem is that Wikimeida uses an outdated version from 2017, see phab:T193352.
Inkscape is developed for generating images, not for batch-converting, therefore it is much slower. (phab:T40010#6635936 @GDubuc (WMF): Can you name the current CPU-costs per day? in CPU-h/d or €/d )
Wikimedia should be used for image-exchange, therefore we don't wan't invalid Inkscape-Files which can only be rendered by Inkscape, we want SVGs that are valid according to the current SVG 1.1-Standard, otherwise it is Inkscape-file but not an more a SVG-file.
SVG-Experts have different opinions on that, because it is a complex topic.
@Glrx: for example: Prefers a native SVG-Rendering by the clients-Browser, however this would be a much larger change than updating or changing the renderer, and has also several disatvantages (Maleware-Safety issues, different rendering on the individual browser, missing fonts, increased client-rendering-time, ...)
I support the proposal, although I expect complications and problems.
However I think resvg by @RazrFalcon: might be a better renderer (very much faster and generally better SVG-Support).
 — Johannes Kalliauer - Talk | Contributions 06:19, 9 December 2020 (UTC)[]
I actually go so far as to oppose this proposal as a waste of time. Work instead on serving SVG directly. Globbet (talk) 22:39, 9 December 2020 (UTC)[]
@Globbet: I might have been unclear about direct SVG-serving, due to security-reasons, unpredicted client-side-rendering, huge SVG-files with several minutes of rendering, it is imho not a good idea in general. Due to different browser you will get several bugs. Brower-rendering should imho only be an opt-in in the preferences for specific flagged svg-files, see Special:Diff/20781745 for details.  — Johannes Kalliauer - Talk | Contributions 10:54, 10 December 2020 (UTC)[]

Voting

  •   Support 4nn1l2 (talk) 18:05, 8 December 2020 (UTC)[]
  •   Support Pmau (talk) 21:38, 8 December 2020 (UTC)[]
  •   Support  — Johannes Kalliauer - Talk | Contributions 06:19, 9 December 2020 (UTC)[]
  •   Support dwf² (talk) 23:03, 9 December 2020 (UTC)[]
  •   Support Ciao • Bestoernesto 03:16, 10 December 2020 (UTC)[]
  •   Support Kizule (talk) 05:36, 10 December 2020 (UTC)[]
  •   Support JPxG (talk) 06:02, 10 December 2020 (UTC)[]
  •   Support Strong support. BoldLuis (talk) 17:58, 11 December 2020 (UTC)[]
  •   Support DemonDays64 (talk) 18:33, 11 December 2020 (UTC)[]
  •   Support Dinock90 (talk) 09:23, 13 December 2020 (UTC)[]
  •   Support Daniel Baránek (talk) 22:48, 15 December 2020 (UTC)[]
  •   Support Stephan Hense (talk) 23:08, 16 December 2020 (UTC)[]
  •   Support Golmore (talk) 11:13, 18 December 2020 (UTC)[]
  •   Support Nadzik (talk) 12:58, 19 December 2020 (UTC)[]
  •   Support 고려 (talk) 11:38, 20 December 2020 (UTC)[]
  •   Support Popadius (talk) 14:31, 20 December 2020 (UTC)[]
  •   Support God, yes! I've wanted to tear my hairs out everytime I've tried uploading a moderately complex image. Uanfala (talk) 23:53, 20 December 2020 (UTC)[]
  •   Support Ahmadtalk 04:34, 21 December 2020 (UTC)[]
  •   Support Wotheina (talk) 05:27, 21 December 2020 (UTC)[]
  •   Support S8321414 (talk) 14:32, 21 December 2020 (UTC)[]
  •   Support — Baidax 💬 17:50, 21 December 2020 (UTC)[]

New Gadget - Mark Files used in a Wiki or Wikidata

Edit proposal/discussion

  • Problem: In the different maintenance categories (~ 650,000 images without category; ~ 50,000 categories with infobox not connected in Wikidata) you could use the connected images to set categories to a Wiki or Wikidata faster or then connect them to Wikidata. At the moment you would have to open every picture and scroll down to see this state.
  • Who would benefit: people who are involved in maintenance; like "Wikidata infobox maintenance" or "Media needing categories"
  • Proposed solution: I would suggest to have a new gadget created, which, if you are in a category, marks the images that are connected to a wiki or wikidata. (Maybe, if it is technically possible, only pictures that are in namespace "0"!)
  • More comments:
  • Phabricator tickets:
  • Proposer: Crazy1880 (talk) 18:11, 25 November 2020 (UTC)[]

Discussion

Voting

Flickr-like uploader

Edit proposal/discussion

  • Problem: Many people in the community would like to upload images on Commons, but they don't wan't to, because they say how complicated it is. Adding description, captions, categories, licences and all those things is a pain. Especially for new users who just want to choose a folder and upload. Skilled Commons users can use Vicuna, Pattypan or something similar, but we are still missing and easy and well working option. We don't have to re-invent the wheel – Flickr has the wheel! We should just mimic what they have. Choose a folder, add all the data in an environment similar to a folder in a computer, do the upload WHILE the stuff is being described and just confirm it by the Upload button. So simple, so efficient and proven to work.
  • Who would benefit: Especially newbies but all Commons users
  • Proposed solution: Creation of a better description of how the tool should be designed and eventually designing and making the tool working.
  • More comments: Note: I've submitted a similiar proposal before. I still believe the community would benefit from this. Lack of such a tool still represents a major bottleneck in better metrics results in many projects we have. The concept of such an uploader would differ from Upload Wizzard – the interface would have to be completely reshuffled and many things must be done automatically.
  • Phabricator tickets:
  • Proposer: Aktron (talk) 10:43, 17 November 2020 (UTC)[]

Discussion

  • How would you add categories to those files? Are they coming with the folder? JopkeB (talk) 16:33, 17 November 2020 (UTC)[]
    • Simple: A filename will be above the icon of the image, description/caption below and category will be below the description. I believe this would work fine with many user cases. Aktron (talk) 15:13, 21 November 2020 (UTC)[]
  • When I upload all pictures of my "DCIM" folder, what do you think should be the caption of each file? What depictions/categories should they have? Surely a generic caption and zero depiction is not a great idea, right? Syced (talk) 13:53, 18 November 2020 (UTC)[]
    • The user should have an option to write a custom caption/description for each file. This is ok if we do maximum accessibility – just like in Flickr you click below an image and directly input the data. No need to load pages, scroll or anything similar. This is what we should do. Aktron (talk) 15:13, 21 November 2020 (UTC)[]
  • What would be the use of thousands of images with no categories and no description? How would one ever find them (without browsing through the uploader's contribs)? However, I agree that adding those new captions is a pain. PiotrekDTALK 15:45, 19 November 2020 (UTC)[]
    • The reason why we have thousands of images with no categories or description is that our tools fail to be easy to use so people can use them to add the data. Adding a description by editing each PAGE of the images is utterly slow. This tool was intened to help this, but it was still limited. So we first need a tool that will allow everyone to easily add caption/description/category to an image or a batch of images. The Flickr uploader is tested and works well, the concept I believe can be easily applied here. Disallowing empty values for caption/description/categories will simply guarantee that we wouldn't have files with no descrition. And we should work with coordinates in a much better way in the future too! Wikishootme is a good start, but let's go further! Aktron (talk) 15:13, 21 November 2020 (UTC)[]
  • I agree. I decided not to provide images any longer to commons because meanwihle it takes me up to 30 minutes to upload a picture (searching for the right categories, addings structured data, creating WD object and linking it...), although I still have thousands of usable images. But this is complex process with many single solutions and does need more than just one request. Many single solutions could help in the future. E.g. a feature that scans the EXIF keywords and suggests categories or a feature that processes the location and time EXIF data and puts it in these time categories "photographs of Germany taken on..." or these lens and camera and aperture categories (including structured data). And finally thinking of introducing tags as well what makes searching easier. -- DerFussi 09:18, 20 November 2020 (UTC)[]
    • I believe the future is when we the Commons will pre-load GPS coordinates from the images and ask you: "This image is within the shapefile: Arc de Triomphe, Paris. Does the image depict it?" And you will click yes and all the data will be added from Wikidata or somewhere else :-) Aktron (talk) 15:13, 21 November 2020 (UTC)[]
      • @Aktron: Its just a bit of help. To be honest - frankly spoken, a wiki is the very last kind of software that should be used as a media repository. The whole commons wiki should be thrown into a garbage can and replaced by a new suitable media repository software. Actually I am curious how many hours and live times the users spent for creating categories by hand (and reorganising them later) and how many hours uploaders spent to find the all suitable categories for a picture (and nobody will find them all), although a handful of keywords/tags in the EXIF data have all the necessary information. I am aware, that we all have to live with that short-sighted decision to use a wiki for commons. But some AI may help in the future to suggest suitable categories after sanning EXIF data (location, coordinates and keywords). -- DerFussi 22:10, 21 November 2020 (UTC)[]
        • Yeah, but Wiki for image repository is kinda like a QWERTY keyboard. The idea is utterly impractical and outdated and yet so many people use it that despite the utter impracticality everyone does it. Aktron (talk) 22:46, 21 November 2020 (UTC)[]
    • “[…] addings structured data, creating WD object and linking it […]” – I find these WD-related parts annoying as well. Actually, what is the point of them? IMO the uploader was better in '17 when there were no fancy “features” like that (if memory serves). Regards, PiotrekDTALK 11:15, 24 November 2020 (UTC)[]
      • They do have a sense but adding them manually just doesn't work. We have made a perfect brick but now we need a perfect machine for laying bricks. Nobody builds a huge structure by laying brick by brick by hand. Aktron (talk) 18:11, 24 November 2020 (UTC)[]
        • Enter the Captain: laying bricks by hand is the only reliable way to lay bricks. Humans tackled the issue of mechanized bricklaying for the past two hundred years, at least, and each time they failed. To eliminate bricklayers, one has to replace bricks with something else. Back to our "bricks", the problem is that only the uploader can describe the contents of the upload. AI systems can sometimes help, but not in the case of original, never-published material (think of the only existing photo of someone's great-great-grandmother...). So, even in foreseeable future, the uploader has to provide meaningful descriptions, typing with their fingers. If it doesn't work now (I know it doesn't, I'm fixing the backlogs at a snail's pace...), it has nothing to do with the "complexity" of the upload form, and it won't work with any alternative upload protocol. Retired electrician (talk) 19:20, 15 December 2020 (UTC)[]
  • I agree. The upload-form is kindof dumb in an annoying way.It does not, but it should support drag and drop and /or point to files in the local image browser. The current method keeps loosing the spot in the local browser if the folder has hundreds of images to pick in a manually selected order of appearance by batches of a few in time. Found out i can drop them on the button. The upload form should remember my only few used languages and have their formfields open and prepared to fill in right away. Now it asks the uploader over and over again which out of hundreds of languages we want to use. At least create a shorlist for this in user prefrences, so language can be picked by typing 1 single letter. (Parts of) carefully crafted titles could be re-used and preproposed as captions, as descriptions and as Data, even as proposed categories. Let users pick and save their preferred upload templates (single file, batch, series, homogenous, misc.) Add buttons troughout the form to copy info from one to the next the file in sequence, not just info from file 1 to all others. Make an opt-out button for reloading page for last step (DATA) or possibly integrate a smarter version (using parts of the already provided info) in the upload form as an optional formfield. Upload form could remember a shortlist of last used categories. Upload form could remember and display till the end of the process, in grey or italics, the old (local) filename for further reference when moving local 'done' files to local 'done' folders, or tagging them alike. Pelikana (talk) 13:07, 20 November 2020 (UTC) Yes, agree ... time could be saved by being able to edit descriptions etc. while the uploads are being done in the background. Pelikana (talk) 16:04, 22 November 2020 (UTC)[]
    @Pelikana Drag and drop upload will soon be improved by T47656. ESanders (WMF) (talk) 18:37, 2 December 2020 (UTC)[]
    I feel neglected because the upload form has never asked me "which out of hundreds of languages we want to use". It's always in plain English. Why such difference in treatment? Retired electrician (talk) 19:26, 15 December 2020 (UTC)[]
    I meant picking the extra especially the 3rd languages for the captions and descriptions is a pain. Say: I want to upload a batch of 10 heterogeneous images and I want to add 2 extra languages for each file description, than I will have to click and pick or type at least 60 times for these 2 extra languages within this short session (unlike the captions that remember my choises). Picking the 3rd language is a 3-click process. So let us select the Constants Caption Languages and Description Languages centrally, in preferences, or at least at the top of the form and apply that choice to all files. Don't treat this choice as a variable, because it's actually a lifelong constant. Don't confront us a n-thousand times in this UploadWizzard with language options that we will never ever pick. Peli (talk) 04:07, 16 December 2020 (UTC)[]
What about the bug: the form tells me that I'm already uploading the file? This erroneous error message pops up every time when I stay on the site an click 'Upload More Images' to do next batch - unless I do a reload of the empty form page first by pressing F5. Can this be investigated please? Peli (talk) 14:44, 16 December 2020 (UTC)[]
It appears that you're using the unfortunate "upload wizard" in place of the regular, wikitext-based upload form. No triple-clicks required there, which probably explains its longevity. Just type in double-character language codes as you would in a wikipedia article or talk page. Retired electrician (talk) 20:44, 16 December 2020 (UTC)[]
  • Seems like a reasonable proposal that would entice me more to start uploading images as well. --Ivario (talk) 22:23, 24 November 2020 (UTC)[]
  • Problems to address: let's please focus on specific problems that make uploading so slow and painful. Copying the fields entered helps, but maybe there should be an option to copy down to any below the current image. Uploading from Flickr should allow you to see more files, and upload from a photostream over just an album. Copyright statuses should be able to be copied; right now they cannot. Errors uploading need to be clearly stated, either easily found or searchable, perhaps by saying "Error: XYZ". Right now, finding the error preventing your upload of 200+ files is painstaking. There's other problems beyond just these... (talk) 04:22, 7 December 2020 (UTC)[]

Voting

  •   Support I agree! Current uploader is just too unfriendly and time consumpting. Lukáč Peter (talk) 18:41, 8 December 2020 (UTC)[]
  •   Support But this will need some pretty exact specifications to make sure it doesn't lead to a mass upload of unusable images. Jo-Jo Eumerus (talk, contributions) 18:42, 8 December 2020 (UTC)[]
  •   Support Martin Urbanec (talk) 22:13, 8 December 2020 (UTC)[]
  •   Support Jan Myšák (talk) 22:28, 8 December 2020 (UTC)[]
  •   Support But, if "flickr-like uploader" will be for newbies, why would disscussing experienced users problems? And i think, that upload-wizard is fully ready for new users. (Do you try this in few last months? I am!) Frettie (talk) 22:49, 8 December 2020 (UTC)[]
  •   Support (talk) 02:13, 9 December 2020 (UTC)[]
  •   Support —— Eric Liu留言百科用戶頁 04:36, 9 December 2020 (UTC)[]
  •   Support ··· 🌸 Rachmat04 · 04:44, 9 December 2020 (UTC)[]
  •   Support Monirec (talk) 09:46, 9 December 2020 (UTC)[]
  •   Support --Krvesaj (talk) 10:14, 9 December 2020 (UTC)[]
  •   Support Lirazelf (talk) 17:04, 9 December 2020 (UTC)[]
  •   Support TheImaCow (talk) 17:09, 9 December 2020 (UTC)[]
  •   Support We need better tools. this proposal should solve the problem with categorisation. And there are many upload(er)s with simple copyying description and filenames, so this tool wouldn't make it worse.. JAn Dudík (talk) 20:03, 9 December 2020 (UTC)[]
  •   Support Patriccck (talk) 20:48, 9 December 2020 (UTC)[]
  •   Support dwf² (talk) 23:03, 9 December 2020 (UTC)[]
  •   Support - Darwin Ahoy! 01:22, 10 December 2020 (UTC)[]
  •   Support Uploading images should be made more user-friendly, at the moment it's too complex and time consuming to encourage users to add more images. Piensaimnieks (talk) 12:59, 10 December 2020 (UTC)[]
  •   Support Agree this is an issue that needs solving, I think some user research is needed to understand the best ways to ask people to add additional information needed on top of what Flickr does, also would suggest looking at Instagram, Facebook etc interface to see if there's anything we could use John Cummings (talk) 17:16, 10 December 2020 (UTC)[]
  •   Support Ján Kepler (talk) 17:44, 10 December 2020 (UTC)[]
  •   Support Libcub (talk) 20:14, 10 December 2020 (UTC)[]
  •   Support Michalskop (talk) 03:14, 11 December 2020 (UTC)[]
  •   Support Paucabot (talk) 12:26, 11 December 2020 (UTC)[]
  •   Support FabianHorst (talk) 17:34, 11 December 2020 (UTC)[]
  •   Support BoldLuis (talk) 17:42, 11 December 2020 (UTC)[]
  •   Support Theklan (talk) 18:09, 11 December 2020 (UTC)[]
  •   Support --Adam Hauner (talk) 21:43, 11 December 2020 (UTC)[]
  •   Support --Alaa :)..! 01:21, 12 December 2020 (UTC)[]
  •   Support ThomasLendt (talk) 15:43, 12 December 2020 (UTC)[]
  •   Support Gnom (talk) 15:58, 12 December 2020 (UTC)[]
  •   Support Geagea (talk) 14:01, 13 December 2020 (UTC)[]
  •   Support Conny (talk) 14:09, 13 December 2020 (UTC)[]
  •   Support Novak Watchmen (talk) 19:54, 13 December 2020 (UTC)[]
  •   Support Podzemnik (talk) 21:08, 13 December 2020 (UTC)[]
  •   Support Vincent Simar (talk) 21:49, 13 December 2020 (UTC)[]
  •   Support Ita140188 (talk) 09:35, 14 December 2020 (UTC)[]
  •   Support Michel Bakni (talk) 14:01, 14 December 2020 (UTC)[]
  •   Support At least 1) make possible to annotate the files while they are uploading 2) make adding categories more intuitive as navigation in cat-tree in HotCat is. — Draceane talkcontrib. 13:23, 15 December 2020 (UTC)[]
  •   Support aber vorher sollte das Hochladen allgemein überhaupt erst wieder repariert werden. --Ralf Roletschek (talk) 18:58, 15 December 2020 (UTC)[]
  • sort of   Support, as long as there is an opt-out provision. I certainly would appreciate a good built-in mass upload tool, but I also remember the spectacular failure of the "upload wizard"... so don't expect much. Retired electrician (talk) 19:34, 15 December 2020 (UTC)[]
  •   Support Q0ywo (talk) 08:56, 16 December 2020 (UTC)[]
  •   Support Please make the UploadWizzard more ergonomic by supplying the option of centrally setting /remembering the few Caption and Description Languages to be used Peli (talk) 12:04, 16 December 2020 (UTC)[]
  •   Support Jurbop (talk) 18:17, 16 December 2020 (UTC)[]
  •   Support Sepehrifar (talk) 08:15, 18 December 2020 (UTC)[]
  •   Support Hgrobe (talk) 09:27, 18 December 2020 (UTC)[]
  •   Support Señoritaleona (talk) 00:41, 19 December 2020 (UTC)[]
  •   Support Jklamo (talk) 15:40, 19 December 2020 (UTC)[]
  •   Support Xulescu g (talk) 14:29, 20 December 2020 (UTC)[]
  •   Support S8321414 (talk) 14:29, 21 December 2020 (UTC)[]
  •   Neutral In my opinion, the UploadWizzard is easy enough to use as it is. Licensing files does require some basic knowledge, and a simpler design won't change that. Nachtbold (talk) 17:34, 21 December 2020 (UTC)[]

Support 360 photo viewing

Edit proposal/discussion

  • Problem: Wikipedia Article/ Media Viewer can't show 360° photos as a 360° because it can't Read/Render necessary 'EXIF metadata tags' from the uploaded photo. When uploading from a 360-ready camera, sometimes 'Metadata Stripping' occurs & there is no 'Exif Editor' in Media Viewer/Commons to do a 'Metadata Injecting'.
 
Just another animated GIF, showing a concept of usability in wikipedia articles.
  • Who would benefit: Editor who want to express the feeling about the surroundings of any place/ architecture in any article.Instead of showing many photos someone can take 1; 360° photo to encapsulate all the information he/she want to show.

Reader who want to feel the surroundings of any Place/ architecture in any Wiki article they read.It puts the reader/viewer in control of what they want to look at within an image, which is like being in the moment when that particular photograph was captured!

Also, Wikipedia's existing 'panoramic photos' look's very small in mobile devices. Adding 360° viewing capability in media viewer will solve this problem.

  • Proposed solution: Integrate a web based 'EXIF editor/Injector' in wikimedia Commons similar to THEXIFER.NET, so that when uploading 360° photos, 'Metadata Injecting' can be possible.

Integrate 'Panoviewer' tool/egjs-view360 into 'Media viewer' & 'Mediawiki's CORE' so that article readers can navigate inside the image by mouse or finger gesture.

An auto generated 'Thumbnail' will be shown in the article when low internet speed/device incompatibility will be detected.

User dschwen did some good work on this.
  • More comments: This has been a wish on the previous wishlists and only slightly missed the Top X several times:
  • Phabricator tickets: phab:T138933
  • Proposer: Ahm masum 30 November 2020 (UTC)

Discussion

Voting

Interactive chess content

Edit proposal/discussion

  • Problem:
    WMF wikis cannot provide interactive chess content which makes it difficult to convey information. Unlike other websites which allow readers to see pieces move on the board or automatically show a game move-by-move, WMF wikis are limited to static content or less-interactive video/gif content.
  • Who would benefit:
    Wikipedias, WikiBooks, and Wikiversity would most immediately benefit. The featured book b:Chess has openings and example games, and providing an interactive board would improve learning by allowing readers to see the pieces move on the board as they would in a real game. Many Wikipedias have articles on famous chess games such as the w:Evergreen game and the w:Opera game. Adding an interactive chess viewer would provide a critical piece of content for understanding these games that is currently missing, and it gives readers greater control over the pacing of movements than a video or GIF. For Wikiversity, which currently has limited chess content, the new functionality would encourage collaboration on v:Chess and other teaching materials. Future versions could incorporate Stockfish, a free and open-source chess engine, which could be used on Wikiversity for automating chess puzzles or writing quizzes. Development would also benefit the wider wiki-community by providing a high end, freely licensed extension for chess wikis like Chess Programming Wiki and WikiChess.
  • Proposed solution:
    mw:Extension:ChessBrowser is a community-developed MediaWiki extension which reads w:Portable game notation (PGN) and displays a board with arrows to progress through the moves of a chess game. It is based on a javascript gadget used on the Hebrew and Russian Wikipedias, but unlike the gadget, most of the extension's code is run on WMF servers so that it reduces the load time for readers. As a community developed extension, developer time is limited and the deployment process is complex. Support by the community development team would ensure that the extension is well designed and that the deployment process runs smoothly and efficiently.
  • More comments:
    1. Co-proposed, revised, and moved from "misc" to "multimedia" section by Wugapodes (talk) 00:02, 29 November 2020 (UTC)[]
    2. in lieu of demo page for the extension (see stalled request phab:T244075), please view the "demo page" for the script used on hewiki and ruwiki, which i set up long ago - w:he:משתמש:קיפודנחש/ארגח 1. hopefully, a real demo for the extension can be set up soon.
      also, see this hewiki article and ruwiki article, and compare each with its English interwiki, to judge the effectiveness and value of showing games interactively. peace - קיפודנחש (talk) 18:23, 30 November 2020 (UTC)[]
    3. see enwiki community consensus here: w:en:Wikipedia:Village_pump_(technical)/Archive_175#Enable_chess_PGN_viewer_for_chess_articles. the main objection was the fact that the proposal was for the "standalone" script rather than an extension.
  • Phabricator tickets: phab:T244076, phab:T244075, phab:T246736, phab:T239446, phab:T248272.
  • Proposer: קיפודנחש (talk) 00:02, 29 November 2020 (UTC)[]

Discussion

  • We've been talking about this for several years at this point. It just keeps hitting snags and losing momentum as far as I can tell. Maybe the wishlist will get it across the finish line. — Rhododendrites talk \\ 01:48, 29 November 2020 (UTC)[]
  • Implementation of this would almost immediately make almost all of our chess-related content on all language Wikipedias and WikiBooks useful to several times more readers and go from incomprehensible to understandable for those without high expertise in chess. It seems like this is not a big task for Comm Tech or something that would interfere with existing projects or interfaces, so I'd ask that it be considered even if it's a bit lower payoff than some larger-scale tasks. — Bilorv (talk) 15:41, 29 November 2020 (UTC)[]

Voting

  •   Support Would be useful to have, volunteer created extension is a good start but could use some WMF support for review and deployment DannyS712 (talk) 18:04, 8 December 2020 (UTC)[]
  •   Support Jo-Jo Eumerus (talk, contributions) 18:40, 8 December 2020 (UTC)[]
  •   Support Sgd. —Hasley 18:42, 8 December 2020 (UTC)[]
  •   Support Interesting! Sannita - not just another it.wiki sysop 19:32, 8 December 2020 (UTC)[]
  •   Support Sabas88 (talk) 22:42, 8 December 2020 (UTC)[]
  •   Support per what I wrote above (and in various places for years) — Rhododendrites talk \\ 00:35, 9 December 2020 (UTC)[]
  •   Support per my comment above. — Bilorv (talk) 01:21, 9 December 2020 (UTC)[]
  •   Support BALA. RTalk 01:35, 9 December 2020 (UTC)[]
  •   Support * Pppery * it has begun 02:06, 9 December 2020 (UTC)[]
  •   Support --Yoavd (talk) 05:10, 9 December 2020 (UTC)[]
  •   Support Lion-hearted85 (talk) 11:49, 9 December 2020 (UTC)[]
  •   Support Петър Петров (talk) 17:52, 9 December 2020 (UTC)[]
  •   Support Useful! --X0stark69 (talk) 19:07, 9 December 2020 (UTC)[]
  •   Support - yona B. (D) 08:03, 10 December 2020 (UTC)[]
  •   Support Mbkv717 (talk) 09:05, 10 December 2020 (UTC)[]
  •   Support 14:21, 10 December 2020 (UTC)[]
  •   Support as it provides engaging interactivity in a manner that will degrade gracefully for readers using browsers with fewer features/resources. Isaacl (talk) 04:32, 11 December 2020 (UTC)[]
  •   Support Stefan Fadinger (talk) 08:41, 11 December 2020 (UTC)[]
  •   Support Theklan (talk) 18:12, 11 December 2020 (UTC)[]
  •   Support Stevenliuyi (talk) 22:20, 11 December 2020 (UTC)[]
  •   Support Cobalt~frwiki (talk) 09:46, 12 December 2020 (UTC)[]
  •   Support There is a dedicated volunteer community of people who produce and publish chess content in other platforms. If we did this, then that community would migrate to the Wikimedia platform because we would meet a lot of needs. The chess community is international, multilingual, highly collaborative, and enthusiastic about data and archiving. Chess articles which could better show boards would translate very well. This is a small technical development which can attract a large volunteer publishing community which needs a multilingual data friendly home. Blue Rasberry (talk) 16:24, 12 December 2020 (UTC)[]
    User:Bluerasberry: actual storage is somewhat a different issue. currently, wikidata hosts several games such that the pgn of the game can be extracted, but i doubt this method is appropriate for large number of games. see, e.g., d:Q936161 and d:Property:P5286. you may want to propose another wish (next time around, maybe) to allow storage of chess games, and optionally "game sets", e.g., for tournaments, in a common repository, either commons, a new one, or some better way to do it in wikidata. see this module on hewiki: he:Module:Chess, which pulls the pgn from wikidata, and can feed it to other templates or modules, either for drawing chess diagrams of any or all positions in the game, or for interactive display. see he:User:קיפודנחש/ארגח 2, and look at its source. peace - קיפודנחש (talk) 19:42, 13 December 2020 (UTC)[]
  •   Support Theshumai (talk) 22:29, 12 December 2020 (UTC)[]
  •   Support Francois-Pier (talk) 23:08, 12 December 2020 (UTC)[]
  •   Support As co-proposer and -developer Wugapodes (talk) 23:13, 12 December 2020 (UTC)[]
  •   Support Cobblet (talk) 00:59, 14 December 2020 (UTC)[]
  •   Support --Sudonet (talk) 16:58, 14 December 2020 (UTC) Yes![]
  •   Support why not? JackFromReedsburg (talk) 01:19, 17 December 2020 (UTC)[]
  •   Support -- Volcanus (talk) 13:54, 19 December 2020 (UTC)[]
  •   Support --Icodense (talk) 19:44, 19 December 2020 (UTC)[]
  •   Support -- DutchTreat (talk) 12:38, 20 December 2020 (UTC)[]
  •   Support -- Steak (talk) 10:53, 21 December 2020 (UTC)[]
  •   Support --Linseneintopf (talk) 15:29, 21 December 2020 (UTC)[]

Photo challenge

Edit proposal/discussion

  • Problem: With a large number of images (> 100), the coordination is very cumbersome and time-consuming.
  • Who would benefit: Wikimedia Commons and all participants in the Photo challenge.
  • Proposed solution: Improvement of the voting through a simple and user-friendly program interface.
  • More comments: It would be helpful, for example, if you could filter out photos that you do not want to award points in order to gradually reduce the number. It may be possible to use the same method as for "Picture of the Year". In addition, a simple integration of the images is desirable, as in my experience this is often done wrong. If it is the aim and purpose of the Photo challenge to win new participants (photos), then IMHO should also provide an adequate user interface.
  • Phabricator tickets:
  • Proposer: F. Riedelio (talk) 10:13, 25 November 2020 (UTC)[]

Discussion

I think this can be the proposal. --BoldLuis (talk) 18:00, 11 December 2020 (UTC)[]

Voting

  •   Support Jarekt (talk) 16:26, 12 December 2020 (UTC)[]
  •   Support ThomasLendt (talk) 13:58, 13 December 2020 (UTC)[]
  •   Support Hu Nhu (talk) 20:38, 14 December 2020 (UTC)[]
  •   Support WTM (talk) 01:21, 15 December 2020 (UTC)[]
  •   Support Kakila (talk) 08:25, 16 December 2020 (UTC)[]
  •   Support as proposer F. Riedelio (talk) 10:02, 17 December 2020 (UTC)[]
  •   Support Risk Engineer (talk) 15:54, 17 December 2020 (UTC)[]
  •   Support Nadzik (talk) 11:50, 19 December 2020 (UTC)[]
  •   Support S8321414 (talk) 14:28, 21 December 2020 (UTC)[]
  •   Support Golmore (talk) 17:45, 21 December 2020 (UTC)[]

Improve graphs and interactive content

Edit proposal/discussion

 
Examples of Vega and Vega-Lite graphs we can build
  • Problem: Wikipedia would benefit from more animations, interactive content, and self-updating infographics
When we discuss historical changes, we should be able to view those changes interactively, e.g. side by side. Statistical data should be represented as easy to understand charts, and when the new data becomes available, those charts should update. We already have some of the tools for this (the <graph> tag, the shared data on commons, maps), but the current tools are hard to use, not maintained, and need improvements. The comprehensive vision was presented several years ago in a short I Dream of Content paper.
The Graph extension has many advantages for Wikimedia projects. In brief, it allows data to by displayed by generating graphs on-the-fly (we do not need a picture file anymore, and so we do not need to create a new picture each time the data are updated). However, the Graph extension is currently not widely used, probably partly because the code is not really user-friendly.

In addition, the current extension has not been able to display Wikidata data for more than a year, and since there is no official maintainer for this extension, the problem has remained ever since.

  • Who would benefit: Readers and content creators
  • Proposed solution: Upgrade the Vega library, add Vega-Lite support, and add multilingual support to Graphs.
Develop a GUI Visual-Editor-like tool to help contributors to create nice graphs. This tool could look a bit like those in spreadsheet software (the user selects the data to plot and the type of graph, then fine-tunes it). This tool could be integrated with the Data namespace on Wikimedia Commons (example) and with the Wikidata Query Service. The latter already offers different visualisation methods, with the ability to export results to several formats (html, json, svg). See this example. Adding customizable Vega code as an output would be nice.
Community Wishlist Survey 2016/Categories/Multimedia#Support SVG interactivity and animation in Media Viewer discussed making animation and interactivity easier for SVGs.
  • More comments:
  • Proposer: Pamputt (talk) 20:25, 20 November 2020 (UTC)[]

Discussion

Voting

  •   Support Dr747 (talk) 18:59, 8 December 2020 (UTC)[]
  •   Support As collective tasks impulsor, I would like to be able to show more graphs with metrics and figures. Noé (talk) 19:32, 8 December 2020 (UTC)[]
  •   Support Owleksandra (talk) 19:33, 8 December 2020 (UTC)[]
  •   Support Yes. Please. Sannita - not just another it.wiki sysop 19:33, 8 December 2020 (UTC)[]
  •   Support Pi.1415926535 (talk) 21:14, 8 December 2020 (UTC)[]
  •   Support Pmau (talk) 21:36, 8 December 2020 (UTC)[]
  •   Support Nw520 (talk) 23:00, 8 December 2020 (UTC)[]
  •   Support BALA. RTalk 01:37, 9 December 2020 (UTC)[]
  •   Support Absolutely essential! --Ita140188 (talk) 04:54, 9 December 2020 (UTC)[]
  •   Support – Minh Nguyễn 💬 07:52, 9 December 2020 (UTC)[]
  •   Support Jcwang1986 (talk) 08:57, 9 December 2020 (UTC)[]
  •   Support Monirec (talk) 09:44, 9 December 2020 (UTC)[]
  •   Support My experiences trying to add graphs and interactive content to articles give me a clear impression that there is a lot to be desired. {{u|Sdkb}}talk 09:56, 9 December 2020 (UTC)[]
  •   Support RobertBlinov (talk) 10:05, 9 December 2020 (UTC)[]
  •   Support -- Triple C 85 |talk| 10:54, 9 December 2020 (UTC)[]
  •   Support Thomas Kinz (talk) 11:32, 9 December 2020 (UTC)[]
  •   Support Vega's interactive graphs are outstanding. It would be a powerful tool to be embedded into Wikipedia. Since the syntax can be quite complex for unexperienced users, a collection of presets and examples would be of help to start editing. Lion-hearted85 (talk) 12:09, 9 December 2020 (UTC)[]
  •   Support NMaia (talk) 12:43, 9 December 2020 (UTC)[]
  •   Support MarioSuperstar77 (talk) 14:16, 9 December 2020 (UTC)[]
  •   Support Sgd. —Hasley 14:22, 9 December 2020 (UTC)[]
  •   Support ForzaGreen (talk) 16:52, 9 December 2020 (UTC)[]
  •   Supportputnik 19:10, 9 December 2020 (UTC)[]
  •   Support Globbet (talk) 22:43, 9 December 2020 (UTC)[]
  •   Support dwf² (talk) 23:04, 9 December 2020 (UTC)[]
  •   Support - Darwin Ahoy! 01:23, 10 December 2020 (UTC)[]
  •   Support We really need a more intuitive way to create graphs. H78c67c (talk) 01:33, 10 December 2020 (UTC)[]
  •   Support JPxG (talk) 05:58, 10 December 2020 (UTC)[]
  •   Support Viferico (talk) 15:52, 10 December 2020 (UTC)[]
  •   Support Sadads (talk) 16:40, 10 December 2020 (UTC)[]
  •   Support This was our readers second most frequent request, after improved mobile, back in 2015. Doc James (talk · contribs · email) 16:55, 10 December 2020 (UTC)[]
  •   Support John Cummings (talk) 17:11, 10 December 2020 (UTC)[]
  •   Support Rodw (talk) 17:11, 10 December 2020 (UTC)[]
  •   Support Graphs are crucial and need to be properly looking and understandable OrCer (talk) 11:00, 9 December 2020 (UTC)[]
  •   Support Better than static SVGs/PNGs, more easy to update with new data. Geraki TL 17:26, 9 December 2020 (UTC)[]
  •   Support Ciao • Bestoernesto 03:11, 10 December 2020 (UTC)[]
  •   Support MichaelSchoenitzer (talk) 18:51, 10 December 2020 (UTC)[]
  •   Support JenOttawa (talk) 19:30, 10 December 2020 (UTC)[]
  •   Support Libcub (talk) 20:08, 10 December 2020 (UTC)[]
  •   Support Afernand74 (talk) 20:33, 10 December 2020 (UTC)[]
  •   Support Srđan (talk) 22:33, 10 December 2020 (UTC)[]
  •   Support Yes! More data viz would be awesome, and animations would be super beneficial and totally enrich articles. Thisisnotcam (talk) 22:36, 10 December 2020 (UTC)[]
  •   Support Michaelelijahtanuwijaya (talk) 03:11, 11 December 2020 (UTC)[]
  •   Support Arnd (talk) 16:55, 11 December 2020 (UTC)[]
  •   Support BoldLuis (talk) 17:45, 11 December 2020 (UTC)[]
  •   Support -Xbony2 (talk) 19:32, 11 December 2020 (UTC)[]
  •   Support 4nn1l2 (talk) 20:06, 11 December 2020 (UTC)[]
  •   Support Vega 2 is old. We need to upgrade to Vega 5. --IngenieroLoco (talk) 21:26, 11 December 2020 (UTC)[]
  •   Support Tuvalkin (talk) 21:36, 11 December 2020 (UTC)[]
  •   Support Oh, DrPizza! (talk) 08:20, 12 December 2020 (UTC)[]
  •   Support Strainu (talk) 10:25, 12 December 2020 (UTC)[]
  •   Support Tom Ja (talk) 11:58, 12 December 2020 (UTC)[]
  •   Support Jmmuguerza (talk) 14:14, 12 December 2020 (UTC)[]
  •   Support Ad Huikeshoven (talk) 14:28, 12 December 2020 (UTC)[]
  •   Support Gnom (talk) 15:59, 12 December 2020 (UTC)[]
  •   Support Snaevar (talk) 16:11, 12 December 2020 (UTC)[]
  •   Support Amqui (talk) 17:40, 12 December 2020 (UTC)[]
  •   Support Yiyi (talk) 20:03, 12 December 2020 (UTC)[]
  •   Support Wostr (talk) 21:07, 12 December 2020 (UTC)[]
  •   Support per my comment in discussion. Wugapodes (talk) 23:12, 12 December 2020 (UTC)[]
  •   Support Francois-Pier (talk) 23:18, 12 December 2020 (UTC)[]
  •   Support The Blinder Grunt (talk) 07:57, 13 December 2020 (UTC)[]
  •   Support TeKaBe (talk) 08:03, 13 December 2020 (UTC)[]
  •   Support Dinock90 (talk) 09:42, 13 December 2020 (UTC)[]
  •   Support // Lollipoplollipoplollipop :: talk 10:49, 13 December 2020 (UTC)[]
  •   Support Geagea (talk) 13:57, 13 December 2020 (UTC)[]
  •   SupportBilorv (talk) 17:27, 13 December 2020 (UTC)[]
  •   Support Izno (talk) 20:26, 13 December 2020 (UTC)[]
  •   Support Podzemnik (talk) 21:13, 13 December 2020 (UTC)[]
  •   Support Kimsey0 (talk) 22:47, 13 December 2020 (UTC)[]
  •   Support Steven Sun (talk) 11:01, 14 December 2020 (UTC)[]
  •   Support —— Eric Liu留言百科用戶頁 12:02, 14 December 2020 (UTC)[]
  •   Support As proposer Pamputt (talk) 15:23, 14 December 2020 (UTC)[]
  •   Support WhatamIdoing (talk) 18:46, 14 December 2020 (UTC)[]
  •   Support CristianNX (talk) 19:48, 14 December 2020 (UTC)[]
  •   Support Vincent Simar (talk) 19:55, 14 December 2020 (UTC)[]
  •   Support Blue Rasberry (talk) 21:07, 14 December 2020 (UTC)[]
  •   Support :) --Yurik (talk) 21:44, 14 December 2020 (UTC)[]
  •   Support --Base (talk) 22:34, 14 December 2020 (UTC)[]
  •   Support --Zache (talk) 08:13, 15 December 2020 (UTC)[]
  •   Support — Draceane talkcontrib. 13:25, 15 December 2020 (UTC)[]
  •   Support GoEThe (talk) 14:35, 15 December 2020 (UTC)[]
  •   Support the graph extension desperately needs some love. Currently it is causing 10% of all our JavaScript production errors partly due to a spike in usage this year. Jdlrobson (talk) 15:52, 15 December 2020 (UTC)[]
  •   Support OPlibertad (talk) 17:05, 15 December 2020 (UTC)[]
  •   Support Utopes (talk) 19:13, 15 December 2020 (UTC)[]
  •   Support Herzi Pinki (talk) 21:08, 15 December 2020 (UTC)[]
  •   Support Bgrus22 (talk) 22:35, 15 December 2020 (UTC)[]
  •   Support Content displaying would take a huge leap-forward with interactive graphs. WindowPain (talk) 02:35, 16 December 2020 (UTC)[]
  •   SupportTeratix 06:39, 16 December 2020 (UTC)[]
  •   Support This is a much and very long needed feature for Wikipedia. I have been quietly advocating for something like this for years now. Discott (talk) 09:46, 16 December 2020 (UTC)[]
  •   Support Will make it easier to keep articles up-to-date in terms of visuals Femkemilene (talk) 11:56, 16 December 2020 (UTC)[]
  •   Support Jurbop (talk) 18:16, 16 December 2020 (UTC)[]
  •   SupportÉpico (talk)/(contribs) 23:46, 16 December 2020 (UTC)[]
  •   Support Keepcalmandchill (talk) 01:21, 17 December 2020 (UTC)[]
  •   Support Michael Childs (talk) 01:44, 17 December 2020 (UTC)[]
  •   Support Sikander (talk) 01:54, 17 December 2020 (UTC)[]
  •   Support G.prof (talk) 15:58, 17 December 2020 (UTC)[]
  •   Support GiFontenelle (talk) 05:18, 18 December 2020 (UTC)[]
  •   Support Xhs 唯心而为 10:57, 18 December 2020 (UTC)[]
  •   Support Dey.sandip (talk) 16:03, 18 December 2020 (UTC)[]
  •   Support more user-friendly interface needed Quedel (talk) 21:32, 18 December 2020 (UTC)[]
  •   Support Ruziklan (talk) 21:37, 18 December 2020 (UTC)[]
  •   Strong support --Joalbertine (talk) 18:33, 19 December 2020 (UTC)[]
  •   Support Carn (talk) 20:16, 19 December 2020 (UTC)[]
  •   Support 5910 C (talk) 21:44, 19 December 2020 (UTC)[]
  •   Support --Mike Krüger (talk) 11:32, 20 December 2020 (UTC)[]
  •   Support Geert Van Pamel (WMBE) (talk) 16:29, 20 December 2020 (UTC)[]
  •   Support Uanfala (talk) 23:57, 20 December 2020 (UTC)[]
  •   Support He's the Billy Australia can't afford (talk) 02:19, 21 December 2020 (UTC)[]
  •   Support Ahmadtalk 04:33, 21 December 2020 (UTC)[]
  •   Support Amir E. Aharoni (talk) 13:07, 21 December 2020 (UTC)[]
  •   Support --Shivanarayana (talk) 15:22, 21 December 2020 (UTC)[]
  •   Support VIGNERON * discut. 16:54, 21 December 2020 (UTC)[]
  •   Support Papuass (talk) 17:00, 21 December 2020 (UTC)[]
  •   Support stjn[ru] 17:15, 21 December 2020 (UTC)[]
  •   Support Nadzik (talk) 17:21, 21 December 2020 (UTC)[]
  •   Support Nachtbold (talk) 17:38, 21 December 2020 (UTC)[]
  •   Support Charles Alexis Gérard (talk) 17:41, 21 December 2020 (UTC)[]

Inline Audio-Player for pronunciations and other usages

Edit proposal/discussion

  • Problem:
    Pronouncation of Beijing
    Audio files can enrich Wikipedia and it's sister project in a valuable way. One use case is adding recordings of the pronunciation of the article's topic to the intro. Projects like LinguaLibre now make it possible to do this on a large scale. But for adding them to the article it would be desired to embed a minimal sized audio player into the text, that can be clicked to hear the audio. So far our audio player (both the old and the new beta-feature) only allow to add a big audio player (on the right), a lot of wikipedias have templates that create an audio icon that links to the file instead:   i, but they have the problem, that the readers' browser leaves the article.
  • Who would benefit: Article editors and readers
  • Proposed solution: Add an inline audio player that looks somewhat like the small version above but if the user clicks the icon plays the file directly. Most online dictionaries have such a feature.
  • More comments: For license compliance there also has to be a link to the file page. Above it's done with the tiny `i` but there might be a better way.
  • Phabricator tickets:
  • Proposer: MichaelSchoenitzer (talk) 10:54, 30 November 2020 (UTC)[]

Discussion