Problem: Currently we can see our uploaded files as a list. Sometimes for searching a some file the mouse overheats from page scrolling. I think it would be a better solution to create the last uploaded files in the form of a gallery.
Who would benefit: All users.
Proposed solution: Create the last uploaded files in the form of a gallery
This would be more useful as a category, so that all images of a user would ba accessible to Cat-a-lot. This would e.g. be helpful when new users throw too many images in too many categories. So why not just a hidden category for every user? With the sorting feature requested before one could order them by upload date. Watchduck (talk) 18:26, 4 November 2018 (UTC)[reply]
Watchduck; In this proposal, I am more concerned with the clarity of the "Uploads" page. The solution proposed by you is good, but I would consider it as a separate proposition. Tournasol7 (talk) 18:45, 4 November 2018 (UTC)[reply]
Overwritten images would probably be too much of a blind spot of the category approach, so I retract that. But it would be great to have Cat-a-lot support on the uploads page. Watchduck (talk) 09:51, 5 November 2018 (UTC)[reply]
@Slowking4: I'm confused by your mention of archive.org. Did you mean flickr.com? I'm assuming you're requesting a tool that lets you search flickr for images that have compatible licenses and then import them into Commons. Is that correct? Would use of this tool be restricted to license-reviewers, admins, and extended-uploaders (similar to UploadWizard's Flickr uploader)? Kaldari (talk) 23:36, 5 November 2018 (UTC)[reply]
no, we have a flickr tool. given the downsizing of flickr, we will need a tool that does the same thing for internet archive. we could use OAuth for access to tool. Slowking4 (talk) 03:24, 7 November 2018 (UTC)[reply]
Note: "Flickr promises it won’t delete Creative Commons photos when it limits free storage" -- excerpt: "In a blog post today, Flickr has clarified that those freely licensed photos will be safe, even under the new limits. Accounts with more than 1,000 photos or videos that are licensed with Creative Commons won’t have that content deleted. That said, Flickr will be blocking future uploads to those accounts on January 8th" -- so this isn't as dire as we all previously thought when they first announced the changes. Quiddity (WMF) (talk) 18:28, 14 November 2018 (UTC)[reply]
@Slowking4: Hi, does the above info resolve the issue? (I.e. If I understand correctly, you (like the rest of us) were worried after the first announcement that came out, that we'd lose access to all the currently CC-licensed images there. Hence you were proposing that we should get prepared to have to scrape those flickr images out of IA's backups of them. However now that Flickr has promised to keep those CC images available for the forseeable future, this is no longer a major concern. If that is accurate, then (in order to reduce the 230+ wishes that we all hope all editors will read through!) I propose archiving this particular wish.) Thank you! Quiddity (WMF) (talk) 18:46, 14 November 2018 (UTC)[reply]
no, i was worried about the over-reliance on flickr. if we had tools for upload from IA, a better partner, we would be less reliant on flickr. we should get prepared to decrease barriers to working with preferred partners, with a history of archive stability. a lack of crisis is not a "do not fix" Slowking4 (talk) 21:56, 15 November 2018 (UTC)[reply]
I support the creation of this IA2Commons tool. I am a Flickr user, all my Flickr images are Creative Commons (over 10,000) but I don't want to pay for the hosting service. I put effort in taking good pictures, and I release them under Creative Commons, and now am I going to have to pay? No, thanks. I think I am moving to Internet Archive, using it like my "new Flickr". So, this tool to move content from IA to Commons will help me a lot. Emijrp (talk) 08:42, 18 November 2018 (UTC)[reply]
Support Yep, on Commons we need to put much more effort for better uploaders. Any step in this direction is good. But you should also consider that once this is done, a heavy campaign focusing on people using IAuploader must be done :-) Aktron (talk) 18:13, 17 November 2018 (UTC)[reply]
@Borys Kozielski: For better understanding of the actual problem to solve, an you please provide a link to a page where the player does not play audio files, plus browser and operating system information? I'm surprised to hear that it does not work for you. Thanks! --AKlapper (WMF) (talk) 15:32, 30 October 2018 (UTC)[reply]
Problem: A 360° Photo is a photo that allow us to view more than just a snapshot of a scene . It even let us view the scene from every angle: above, below, behind and next to us & it's also a mainstream media type.
But wiki Articles can't render it & MediaViewer doesn't support it. Images are shown as on the right instead of like this , in the articles.
Who would benefit: All the Readers and editors of wikis. 360° photos are effective for showing off vistas, internal architecture and more in a dramatic fashion that replicates the experience of being there.
Instead of showing 15 photos we could take 1; 360° photo to encapsulate all the information we want to show.It's Also a good way to view panorama photos on mobile devices, where panoramas otherwise are real small.
Proposed solution: Add support to MediaViewer and to the renderd articles to allow to navigate inside of the image by mouse or finger gesture.
THE "panoviewer" uses the Tool Labs grid for job execution and a library for tile manufacturer; theoretically it could be made into a real extension, with the tile manufactory put onto the Services cluster. This would allow it to be deployed everywhere, not just on Commmons, and integrated into MediaViewer officially .Then we can make it as a part of mediawiki software.
Admin, Developer "dschwen" did some good work on this.
More comments: This has been a wish on the previous wishlists and only slightly missed the Top 10 twice. Proposed in the 2016 survey by Ahm masum, ranking at #15 and 2017 by TheDJ ranked #11.
It is gorgeous but slow. In the proposed deployment, what will be the effect on readers with low-bandwidth connections or older hardware? Will there be a note in the image frame saying you can drag it (an automated image-frame link to Commons annotations would also be good)? HLHJ (talk) 04:39, 18 November 2018 (UTC)[reply]
Excellent Question.I think there will be a "Fallback " like all other standard web developments.
360° photo. You can navigate
The interior of the Chapel Royal in Dublin Castle.
when a user's device have low-bandwidth or hardware/software limitation (older) they will get the unrendered version as shown above.it can also have simple alert message like the right photo . And the rendered version could have a simple "info massage" like the left photo(just assume it's a rendered version). "auto generated" message would be more practical for this purpose.
Well , you got the right idea. I have to give you that . I also think the "image annotation" gadget could be a huge help for 360° photos. it can highlight the features we want to focus. Small details, or points of interest within the 360° photo. but it's a huge work for tech team to make it possible. first, the "image annotation" gadget will have to work on 360° & rendered articles . Then these "annotations" have to be mobile friendly, cause 70% +~ wiki users use mobile/smartphone.so it's a complex tusk. Need a huge time & resources.
And we have to make it in such a way so that it can 'distinguish 180°' & 360° and render it accordingly in the article (maybe by using metadata or image recognition algorithm). and the gesture control could be similar to facebook 360. when viewing in mediaviewer it could provide some extra navigation / interaction features & controls...THANKS AGAIN, FOR YOUR QUESTION.-- Ahm masum (talk) 13:03, 20 November 2018 (UTC)[reply]
Problem: When we view a scanned book in PDF or DjVu format in Commons or Wikisource, its always single-page view. Every-time we go to the next page, we need to click on the drop down menu of pages. See this book in Commons for example. For book readers, its more like viewing images than reading books. This not only creates difficulty in reading, but also in identifying missing, duplicated pages etc. if the file needs to be corrected.
Who would benefit: Commons & Wikisource editors and readers
Random-access page selection should remain possible (i.e., if I want page 234, I should not have to click 234 times to turn 234 pages). An interface allowing page turning either by scrolling or by clicking would be good, as some people find the one or the other physically difficult. Something which would aid OCR copyediting/transcription might also be nice. The phab page has some examples of interfaces. HLHJ (talk) 01:26, 31 October 2018 (UTC)[reply]
Hi Bodhisattwa. This problem is something Community Tech would love to work on. It's not clear that the proposed solution is the only or best way to fix it, however. I'd like to invite you to change the title of the proposal to focus more on the problem you want addressed than on the specific software you have in mind as a fix. This will not only make the title more accurately reflect how Community Tech would tackle this problem, it will make the proposal more appealing to the many people who've never tried the IA BookReader but who may have experienced sub-parr pdf reading. Good luck! —JMatazzoni (WMF) (talk) 17:09, 31 October 2018 (UTC)[reply]
An alternative proposal would be to integrate an IIIF service for serving Commons files (phab:T187872). There are a number of different viewers out there than can present content from IIIF sources, including ones offering views quite similar to the IA viewer, and ones that can have their appearance configured using optional stylesheets. I would agree that the IA viewer interface is particularly good, and should be a recommended model for such things. Jheald (talk) 20:47, 5 November 2018 (UTC)[reply]
In fact, I've since learnt that the IA viewer itself can take an IIIF Manifest to specify its input data. So if we could get that going, it would simply be a matter of including a choice for the user to see IIIF content rendered in/by the IA viewer. Jheald (talk) 15:14, 14 November 2018 (UTC)[reply]
Bodhisattwa I am going to rename this proposal so the title is more generic (many people may not be familiar with the Internet Archive BookReader) and also so it gives us more room to experiment with different PDF readers in case implementing a different one is easier/better. I hope that is okay. Please do let me know if you have any concerns. Thank you for the proposal. -- NKohli (WMF) (talk) 18:56, 14 November 2018 (UTC)[reply]
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.
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.
One problem here is that this feature will depend on images to never change. For example, if someone's face was cropped from an image in wikitext like this: [[File:Foo.jpg|crop=320x240|cropoffset=50,60]] and then someone reuploaded Foo.jpg with frame removed, the offsets will change and a wrong part of the image will be cropped. MaxSem (WMF) (talk) 23:48, 2 November 2018 (UTC)[reply]
Thanks for your comment. I just copied the reply from previous discussion. I think, that 99.9% of images will never change.
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.
I'm an editor on Wikisource, and, we need lots of illustrations printed in original work, especially for old galleries. I am currently thinking about developing a tool that makes a cropped image from original source on Commons. If we can instead support this proposed extension, or at least host an image cropper at Toolforge and make a log of every images uploaded via the tool, Wikisource editors will save a lot of time and readers can see more images on Wikisource.--Midleading (talk) 06:13, 4 November 2018 (UTC)[reply]
One example are matching images where a small object is scaled in proportion to a big one, which leads to a margin.
I often have that with different polyhedra around the same midsphere, as seen on the right.
Another example are of course collages like the one shown on the right. An aspect that I would like to bring up is that categorizing such collages can cause confusion, because it is not clear which aspect of the collage is categorized as what. In this case I have chosen to categorize only the cuboctahedron image under cuboctahedron etc., link the collage on the crop's page, and thus consider the collage to be categorized through the crop. Maybe for collages a category could be added like an annotation, and then only the crop would be shown in the category page — maybe even with an automatically generated locator like it is common in maps. Watchduck (talk) 11:04, 5 November 2018 (UTC)[reply]
A twist on this request would be the ability to define named crops of an image in the metadata in the Commons file page, and then to be able to access them using some syntax like [[File:MyPic.jpg#crop1]]
A further change to the landscape will be if/when an IIIF image service gets integrated into the Commons image-serving back-end, see phab:T187872. (There used to be a trial service piggy-backed onto the infrastucture behind the Commons Zoomviewer, but both are currently down). An IIIF service would, amongst other things, allow image crops to be requested directly from the file-server, without having to be cut down by CSS. Jheald (talk) 21:34, 5 November 2018 (UTC)[reply]
@Jheald: "define named crops of an image in the metadata in the Commons file page" I like this idea. I think it's a better approach than most that have been suggested wrt to cropping so far. Be sure to document it in the relevant tickets. —TheDJ (talk • contribs) 10:18, 6 November 2018 (UTC)[reply]
Oh, and I note that our current image service technology (thumbor) also supports serving cropped versions of images. It's probably not enabled, because there is nothing in the stack that would be able to use it, but internally it could easily be used as a cropping service. —TheDJ (talk • contribs) 10:21, 6 November 2018 (UTC)[reply]
Support It's annoying to download and re-upload for the sake of a crop, and some editors crop JPEGS lossily; doing it in the browser would solve both HLHJ (talk) 04:42, 18 November 2018 (UTC)[reply]
Support I support for use case and problem of needing a way to easily show parts of an existing image on a page. However, in terms of implementation, I don't think we should make it a file-syntax parameter. This creates additional software complexity and infrastructure overhead. Perhaps it would be better if we make it really easy to create a cropped version of an image from different places (from the File description page, and from inside wikitext editors and VisualEditor). For example, you edit a page, search or specify the file to use, then automatically see existing crops, and with an option to create a new crop, then simply drag and adjust over the image preview, maybe give it a label, and in the background it will automatically upload, tag and insert the newly created file in the editor. Krinkle (talk) 02:26, 22 November 2018 (UTC)[reply]
Problem: While Wikimedia has a pretty nice archive of MIDI files, they are not playable in modern browsers. Pages will have them available, but they need to be downloaded, and then played on a separate player. Said player is not even necessarily available in the user's operating system, and third party players tend to be a bit tricky to set up, requiring addtional files (soundfonts) and such.
Who would benefit: People who want to listen to our MIDI archive. People visiting several Music-related pages. People who wish to upload small files that illustrate a musical concept.
Proposed solution: Automatically convert the MIDI to Ogg Vorbis, like with other audio files. These are playable on modern browsers.
More comments: We already have most of the necessary software. There is a SCORE tag extension that allows for Lilypond markup, and takes the rendered MIDI and converts it to OGG. And we have the workflow already setup for other conversions. The only optional new item that might be useful is an additional soundfont: the one from MuseScore might fill in gaps in the existing FluidSynth ones and is hiqg quality.
@Trlkly: There is actually an English Wikipedia template, w:en:Template:Synthlisten, which allows MIDI files to be played through the Score extension. (My proposal is somewhat similar but proposes that MusicXML/MuseScore files be uploadable and rendered by Commons/Extension:Score, which would achieve roughly the same but also allow the files to be shown as sheet music.) Jc86035 (talk) 11:22, 11 November 2018 (UTC)[reply]
Trlkly, could you please clarify if you mean automatically adding a Synthlisten template to each MIDI file page, making a downloadable Ogg Vorbis version available for each MIDI file, or replacing the MIDI files with Ogg Vorbis files, thus removing access to the MIDI files as MIDIs?
Comment Added the phabricator task for moving the MIDI to OGG (sound) conversion to TimedMediaHandler, which is used for videos and audio on Wikimedia. This is important so that we aren't bound to using the Score workaround, and so is the cornerstone of this proposal. Another task could be created for it to be automatized for all MIDI files in presentation. Ebe123 (Communication | Activity report) 01:50, 19 November 2018 (UTC)[reply]
Comment I believe this could easily be solved with the VLC API which is free to use, and open. Allowing for a forward facing player without loading extra modules!!!!Lostinlodos (talk) 19:38, 20 November 2018 (UTC)[reply]
Partial support; I support automatically adding a Synthlisten template to each MIDI file page; I do not support removing access to the MIDI files as MIDIs. HLHJ (talk) 04:20, 18 November 2018 (UTC)[reply]
Support I do not think anyone is proposing to remove access to the raw MIDI files, @HJHJ:. This would be a big improvement in musical articles with the flexibility of MIDI files with the convenience of in-browser playability. (Maintainer of the Score extension) Ebe123 (Communication | Activity report) 01:50, 19 November 2018 (UTC)[reply]
Problem: When clicking on a image it is opened in the so called Media Viewer. If the resolution of an image is sufficient it viewed screen filling. SVG files are vector files and can therefore be scaled arbitrary large. But SVG-Files contain image-sizes. Media-Viewer shows SVG-files only as big as the image meta data tells the image is large. Therefore sometimes when clicking on an image to see it larger is is opened not larger but sometimes even smaller than shown in the article, even through it's a arbitrary scalable graphics.
click on me (with MediaViewer enabled)
Who would benefit: Readers
Proposed solution: If the SVG has no bitmap-image embedded show it always screen-filling.
This seems to sort of break the standard. Could we have a tool for rapidly rescaling images with ludicrous embedded scales instead? HLHJ (talk) 08:34, 14 November 2018 (UTC)[reply]
Oppose, as I would prefer fixing silly SVG scales to a standard-breaking kludge. A template for tagging them would be good. HLHJ (talk) 04:54, 18 November 2018 (UTC)[reply]
Problem: IIIF was created to allow the sharing and interoperability of high quality zoomable images both for viewing but also for annotating. Version 3 of the presentation API now also supports audio and video. This proposal is for WikiCommons to support the IIIF Presentation API by exposing IIIF manifests and coining static Canvas IDs. A IIIF Manifest is a JSON-LD metadata representation of a Book, Painting, Archive or Video that can be imported into various tools and viewers. A Manifest contains a number of Canvases, one for each page. A static Canvas ID will mean items in Wikimedia Commons can be annotated using the W3C Annotation Framework and existing IIIF tools.
Images in WikiCommons are difficult to annotate as the image URLs are not static and access is limited to a number of pre-generated sizes. The interface on WikiCommons could be improved for ‘book’ like objects.
Who would benefit: All Commons users
Proposed solution: Expose WikiCommons data using the IIIF standard and in particular mint static Canvas Ids and Manifest Ids.
More comments: This would help with the Book Reader wish as the Internet Archive Book Reader is IIIF compatible.
Tom Crane has the following proof of concept: https://phabricator.wikimedia.org/D1122 which takes Wikidata items which have the P2677 relation (relative position within image) and turns them into IIIF manifests and annotation lists. These manfiests can be viewed and compared in a IIIF viewer like Mirador. This is an extension to a tool called tool-wd-image-positions written by Lucas Werkmeister and as such will only work with items that have the P2677 property.
Tom also has the following project: wikipedia-to-iiif which works with any content in Wikimedia Commons and creates a IIIF manifest. This uses the Wikimedia API to create manifests using static images provided by Wikimedia Commons. The benefit of taking this work and embedding it into the core Wikimedia Commons code is that it would give static URIs for manifests and canvas ids allowing annotation. This is further discussed in a gist.
It's important to note that implementation of the IIIF Presentation API is not dependent on implementation of the IIIF Image API. You can share, annotate and remix images without the tiled deep zoom provided by an image server. Implementing the IIIF Presentation API could also mean that, as well as their current formats, Wikidata query results could be available as IIIF Collections. I could attempt a POC for this too if it would be useful. As an example, this IIIF Collection: Pencil works, Wellcome Library is available for visual re-use, such as here: http://tomcrane.github.io/wellcome-today/today.html?collection=https://wellcomelibrary.org/service/collections/genres/Pencil%20works/
By exposing result sets as IIIF Collections, those result sets can be consumed by IIIF-aware applications, such as a crowdsourcing tool or an image analysis project; IIIF removes the need for a bespoke mapping, and new data generated by those clients addresses the digital object in a standard format, W3C Web Annotations.
Problem: Tabular datasets in Commons cannot contain non-CC0 information because the interface doesn't support the correct attribution
Who would benefit: Wikipedians could move the data tables from the article text, and generate dynamic tables or graphs from it through the Graph and Maps extensions
If this data were in a table, would I have to license it under CC0? How could I claim copyright over basic physical properties of the universe? "Quark masses, copyright User:HLHJ" is absurd.
Support. If the blocking technical requirements are those listed at phab:T154071#4323571, they don't look they would require too much to fix, and should be well within the capabilities of the Community Tech team. Shapefiles that are licensed ODBL, eg from OSM, could be of huge usefulness in connection with WDQS queries. Jheald (talk) 22:59, 5 November 2018 (UTC)[reply]
I've already taken data published under another CC license in a scientific paper and made it into a datagraphic which I uploaded to Commons. It's vector-format, so re-extracting the original dataset would be fairly simple. If I've understood, the status quo means that that was OK, but if I put the data in a table and then made a graph I'd be unable to do so legally due to interface limitations. One might argue that scientific data is not copyrightable (I sort of assumed that, and I was following longstanding academic convention), but that's not the same as a CC-0 license. I'd feel stupid placing an unoriginal table of properties of the universe under CC0. And my original work in making a graphic, is that my copyright that I must license? Can I license it differently from the data? Are recently-invented standard statistical visualization techniques copyrighted? I'm confused. I have no idea how to license data correctly, and excluding scientific data from Wikipedia is clearly not the answer.
Support; we need more guidance on this, and the existing option is not adequate, as some data is not copyrightable and some is under copyleft database licenses. HLHJ (talk) 05:58, 18 November 2018 (UTC)[reply]
Problem: Both Wikimedia video and audio player looks very old. Once I thought the audio player was finally updated, but it was just default Google player, which was shown until Wikimedia's one loaded. Today, there are many trends, like Google Material Design, and it's important to have a modern look. So, please, make it modern, less square, (maybe more round), maybe you can have an inspiration from Google's Material Design. Just make it look like not from the previous decade. Many thanks!
Who would benefit: Everybody reading articles on Wikimedia projects
Proposed solution: Make new design both for audio and video player
@Luky001: What is a "Google player"? (Did you maybe mean the default player shipped in some Google browser that you're using?) "Google Material Design" seems to be en:Material Design. Am I correct that the current "Problem" description above basically says "I don't like how it looks" but does not cover any functionality/workflow issues? --AKlapper (WMF) (talk) 13:02, 2 November 2018 (UTC)[reply]
I meant the default player in Chrome, e.g. when you open MP3 sound file in Chrome, there is the default one. Yeah, you assumed it correctly, I don't like how it looks, but functionality is OK. It's just the thing that I think that we should have modern look for these players. Wikipedia graphics are regularly updated, for example buttons got a new look in the past years, pop-up messages (when you are editing, etc.), etc. Why shouldn't we then update the look of these players? --Luky001 (talk) 15:36, 2 November 2018 (UTC)[reply]
@Luky001:, could you expand more on what benefit this would have to multimedia content? For a stronger proposal I'd encourage a reason for why engineers (and designers!) should spend time on this. What would a "modern look" mean for the projects and movement? How would it improve things?
It would look nicer. It's like comparing Wikipedia now and 15 years ago - we have nice buttons now (instead of basic ones as it was before), nice Recent changes page, in which you can navigate easily, Visual Editor, which made editing of Wikimedia projects much easier, and much more. Everything on the Internet is changing now to better design (minimalistic, clean, etc.). Displaying images wasn't always done in Media Viewer, and it looks great now thanks to it. So from my point of view, it's because I want it to look modern and nice. It is not something revolutionary, but it will look better. --Luky001 (talk) 17:12, 2 November 2018 (UTC)[reply]
@Luky001 and CKoerner (WMF): There is already a working demo of the in-development new video player (thanks to Jdforrester (WMF) for showing it to me). (For it to display you need to enable the Beta Feature for it after creating a new account on the test wiki.) Its styling does look a little like the OOUI buttons', but it seems slightly different to me. I think it would be better to reframe this proposal as a request to finish development of that media player, since there has already been a substantial amount of work done for it. Jc86035 (talk) 16:35, 3 November 2018 (UTC)[reply]
Problem: Data formats for chemical structures exist for long time: w:Chemical Markup Language, w:en:Protein Data Bank (file format), but WMF projects on chemistry topics still used rendered files, generic SVGs and projections of 3D structure on plane without possibility to view structure in 3D.
Who would benefit: All editors who work on chemistry topics.
Proposed solution: WMF need to allocate resources to add support for feature proposed back into 2008 or may be one of local chapters may take a lead on this as Wikidata was implemented by Wikimedia Deutschland.
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!
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!")
Further comments: Since 2015 is there a Phabricator ticket ( https://phabricator.wikimedia.org/T120454 ) 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 ( https://phabricator.wikimedia.org/T120454 ), der dem nahe kommt. Ich habe aber den Eindruck, dass das Projekt nur wenig voran kommt.")
There has been a similar discussion around private drafts which has tended toward "Legal has looked at it and mostly said it's not a good idea for a few reasons". --Izno (talk) 02:27, 6 November 2018 (UTC)[reply]
User:Bluerasberry (see "Voting"): "We do this somewhat at commons:Category:Undeletion_requests" - I didn't know that. Could this be simplified/automated (for example, as an upload wizard special function)? --Molgreen 14:49, 18 November 2018 (UTC)
User:Redactyll (see "Voting"): "I'm in to this idea, seems good enough" (copied from Molgreen 06:52, 28 November 2018 (UTC))
User:HLHJ (see "Voting"): "if legally possible" - Yes, that's a requirement. Therefore the idea with the private sphere (digital legacy) Molgreen14:51, 18 November 2018 (UTC)[reply]
User:Syced (see "Voting"): "I have tons of pictures of modern art and election leaflets. All will die with me if no easy-to-use upload system become available. Deletion of one's pictures is currently a traumatic experience, maybe the process should reworded and split between "useless pictures" and "pictures not publishable yet". For the later, a reconsideration date should be set as metadata to the picture, typically at the expected end of its copyright. Until the copyright ends, the media's page should show the metadata and a 30x30 pixels preview (expect in the rare cases when even such a tiny preview is not lawful) so that people know that the media will become available in X years due to law Y (that might even raise awareness about copyright laws). Thanks!" (copied from Molgreen 18:34, 19 November 2018 (UTC))
You can do this on the Internet Archive (it's routine over there), the Wikimedia wikis don't seem very suitable. Nemo22:33, 27 November 2018 (UTC)[reply]
User:ShakespeareFan00 (see "Voting"): "At least until WMF legal had a chance to fully review what changes Article 13 and it's equivalents will mean in terms of the ability of WMF project to host certain types of content." (copied from Molgreen 05:46, 28 November 2018 (UTC))
User:Kirbanzo (see "Voting"): "but we will need to adjust it if Article 13 is passed in the European Union" (copied from Molgreen 05:48, 28 November 2018 (UTC))
SupportSyced (talk) 03:56, 19 November 2018 (UTC) I have tons of pictures of modern art and election leaflets. All will die with me if no easy-to-use upload system become available. Deletion of one's pictures is currently a traumatic experience, maybe the process should reworded and split between "useless pictures" and "pictures not publishable yet". For the later, a reconsideration date should be set as metadata to the picture, typically at the expected end of its copyright. Until the copyright ends, the media's page should show the metadata and a 30x30 pixels preview (expect in the rare cases when even such a tiny preview is not lawful) so that people know that the media will become available in X years due to law Y (that might even raise awareness about copyright laws). Thanks! Syced (talk) 03:56, 19 November 2018 (UTC)[reply]
Strong opposeShakespeareFan00 (talk) 22:06, 25 November 2018 (UTC) At least until WMF legal had a chance to fully review what changes Article 13 and it's equivalents will mean in terms of the ability of WMF project to host certain types of content. ShakespeareFan00 (talk) 22:06, 25 November 2018 (UTC)[reply]
Problem: With the advent of the IPhone X and the Windows updates people are moving toward a widespread usage of augmented reality applications. If Wikipedia doesn't start to prepare for the future now, people may at some point still read texts that originate from wikipedia, but are presented by social media platforms and presented with non-free media, that was not uploadad to Wikipedia, but to proprietary non-free repositories.
Who would benefit: Photographers and Videographers, who can start to contribute content for future AR use, authors who can use VR content, readers, who can view Wikipedia in 3D, deverlopers, who have access to a large repository of 3D content
Dem Wahren Schönen Guten (Click image to view in 3D)
Proposed solution:
add media type jps to allowed upload formats in commons.
tag uploaded videos in cardboard, sbs and ttb formats in Commons as 3D.
turn toollabs Stereoskopie into a mediawiki extension
support viewing of 3d media in MediaViewer
make the android app functional (modes for single device, 2 devices, viewing of content)
add app for iOS (or create a Arduino HID project to release cameras via KeyEvent.Volume_Up)
make the stereoskopie desktop app functional
empower kiwix to support VR
A Wiki-article employing threedimensional media
More comments:
Stereoscopy has always suffered from two problems: The sparse availability of affordable cameras. And the problem, that the recording system had to match the viewing system - and for both parts there always was a large number of systems to choose from. This proposal addresses both fields:
An app is offered, that turns every camera, that can be controlled with bluetooth or wifi into a stereoscopic camera. And every pair of pictures (old stereoscopic pictures already available at commons, pictures that have been taken with a single camera, that has been moved between to takes) can be converted into a jps-file with the desktop-app.
One source (an image in the standard jps-format, a video in sbs, cardboard or top&bottom format) can be played out in basically every thinkable 3D-system (cardboard, 3DTV, pol (cinema system), prisma, anaglyph with any color code and also with systems, that do not require glasses at all: lenticular, crossed eyes and holographic pyramid). New playout-variants can be added and will work with existing content.
The Stereoskopie project is unfinished. A conversion to PHP, load scaling, robust caching and a Wiki-CI UI will need to be made. Content on the demo page will be added before voting starts.
Hi Gradzeichen. This wish is a little too big for all the work involved. I'd encourage you to split it up. Maybe keep this proposal only about converting the tool to an extension and propose other wishes for supporting 3D viewing and making app(s). Thank you. -- NKohli (WMF) (talk) 17:59, 31 October 2018 (UTC)[reply]
I will not split the proposal, so that the votes get not splitted. However, if the proposal gets voted into the top 10, the wishlist team may implement as much of it, as resources sensibly allow. For a start upload of jps-files could be allowed, then 3D (image and video) files may be tagged automatically, so that they can be excluded or included to search, then the MediaViewer could be enabled to only show the left half of a file for an 2D display of the file, and than go on how far it is possible. Sources of my implementation of the algorithms can be found at github, and may (or may not) be helpful. --𝔊 (GradzeichenDiſk✉Talk) 15:17, 2 November 2018 (UTC)[reply]
Gradzeichen Okay. In that case, I would encourage you to rename the proposal to be more generic so people will click on it more. Most people might not be aware of what Stereoskopie is and that could discourage them from clicking on the wish and reading the description. -- NKohli (WMF) (talk) 18:36, 2 November 2018 (UTC)[reply]
I have tried to come up with another name, that is catchy to native speakers and understandable to others and still decriptive to the proposal. I have contempleted, if the original name should still be appended or not. But I have not come to a solution. Maybe you have an idea? --𝔊 (GradzeichenDiſk✉Talk) 15:10, 4 November 2018 (UTC)[reply]
What do you think of this - Add support for 3D content in Wikimedia wikis? I think it is catchy, understandable and preserves most of the proposal . -- NKohli (WMF) (talk) 00:04, 6 November 2018 (UTC)[reply]
The title is only there to give a high-level idea of the proposal so people click through and read the proposal. It's not a great idea to try to get all the details into the title. :) -- NKohli (WMF) (talk) 18:39, 6 November 2018 (UTC)[reply]
Support That'd be great to support this type of content. Maybe it won't be used that much, but that'd be great to be able to use it, at least. Poslovitch (talk) 20:22, 22 November 2018 (UTC)[reply]
Problem: Animated Gifs are an important way of illustrating some concepts. But they can also be extremely distracting and annoying while reading text near to them.
Who would benefit: All readers and editors
Proposed solution: Add a lite icon to allow to stop the animation. If the icon is pressed stop the animation and replace the icon with another icon that allows to resume the playback.
More comments: The nowerdays defunct Firefox-Addon Toggle animated GIFs implemented this very nicely.
Animation without a pause/unpause button is listed as an accessibility issue by the WCAG. So, this might be a reasonable add for a gadget. --Izno (talk) 23:52, 8 November 2018 (UTC)[reply]
Problem: Downloading a video and Editing to cut videos in Wikimedia Commons locally to finally upload it again to commons is quite time consuming and data consuming.
Who would benefit: Volunteers who cut videos in Commons to improve (Ex: We are uploading entire movie articles into commons and we need to cut them into several small videos to make use of them in different Wikipedia pages.)
Proposed solution: To create a tool like CropTool for videos to cut them and upload separately without downloading, editing locally and uploading again.
This sounds feasible and in scope to me but I'd like the opinion of someone who knows about these things, to make sure the scale is not beyond what Community Tech can manage. Brion Vibber (WMF) can you please have a look? How hard would it be for CommTech to build a simple tool for (if I read this correctly), 1) trimming the beginning and end of a file and 2) cutting it into more than one piece (which, it strikes me, could be done with #1 as long as you can save the file with a new name)? —Jmatazzoni (talk) 23:50, 5 November 2018 (UTC)[reply]
This file is an example File:Missamma Full Length Telugu Movie -- N. T. Rama Rao, A. Nageswara Rao, Jamuna, Savitri.webm. This is a Telugu movie. There are several songs, scenes, etc., which will be useful in several film articles and non-film articles. We have many movies as such. I am trying to find such songs or scenes already there in Youtube to upload and often I have to deal with promotional content of the channel (promotional videos at the end) and you can see some examples in Category:Telugu-language media. I wish we can use this trimming tool to get rid of those issues. Also those songs and scenes are worth being separate videos because they can be used in several articles in Telugu and English Wikipedias. --Pavan santhosh.s (talk) 06:59, 20 November 2018 (UTC)[reply]
Could this be done not by editing the original file but by adding specific time codes etc to the code where its embedded? Simplifying the process of using specific sections of video and audio files would be extremely helpful. John Cummings (talk) 15:07, 19 November 2018 (UTC)[reply]
If we can trim those videos and create a new file, then many others will use it. For example, a separate video of a song from a movie will be used better than time coded video from entire movie. --Pavan santhosh.s (talk) 07:31, 20 November 2018 (UTC)[reply]
Problem: Instant Commons is a fine feature for non WM wikis - but adding content to Commons from a non WM Wiki is not possible.
Who would benefit: All Commons users
Proposed solution: Development of a MW Extension (compatible to standard MW) with an upload wizard to Commons allowing users of non WM Wikis to add proper licensed free content without leaving their wiki.
Thank you @AKlapper (WMF):. Did'nt know Glam2Commons. But it doesn't fit. I'll try to give you something like a user story for my (our) needs: I am contributing to a local free content wiki project (w:de:Regiowiki). Easiest way to contribute photos is to upload them to this local wiki. But if I want to share my pictures with a larger community I can upload the photos to Commons and add them to the local wiki. Adding photos from Commons is easy as the administrator of the local wiki enabled the instant commons option of MediaWiki, but the upload process forces me to leave the local wiki to login into Commons, upload the photo there and switch back to my local wiki article. Better would be to have an option in the local wiki for uploading to Commons, entering Commons credentials there, have a guided process for a proper license and description and be able to proceed editing my local wiki article without leaving. --Friedel Völker (talk) 05:28, 5 November 2018 (UTC)[reply]
Problem: Many graphics included in Wikipedia articles are maps in which countries are color coded according to whatever criterion. Usually this is done by taking a blank map like File:BlankMap-World6.svg, coloring it and then uploading it as a new file. This has a couple of disadvantages:
Fiddling with SVGs is difficult for less tech-savvy users and scares them off
→ Often the user who plans the map is not the one who actually creates it → Lots of communications overhead, not possible to "be bold" and do-it-yourself, lots of time wasted and poor efficiency
→ probably a lot of maps not realised at all because too complex technology is in the way
Lots and lots of redundant information → if a much-used template file receives a change (think new borders, code errors etc.), this change would need to be implemented in hundreds and thousands of files. Of course no one does this → existing files are becoming more and more incorrect (e.g. there are many maps that still don't show South Sudan or other relatively recent changes)
The resulting maps have all sorts of designs, depending on which template file was used
If a user makes a bad choice of template file (e.g. unsuitable projection etc.), it is fairly complex (and takes a lot of effort) to fix that
Example: The following maps are based on the same geographical information but present different data. Each time the map of 12 MB is copied and modified:
Who would benefit: All users who want to include color coded maps. The ones who DO know how to make maps are currently wasting a lot of time, too.
Proposed solution: Defining the map data (borders etc.) should be separated from the map styling (colors etc.), so that the end user doesn't need to do any more than fill out a simple template: {{Map Europe|de=red|fr=blue|it=green}}. Commons should host the template maps as .map pages, which can then be modified conveniently (via the template, using the graph extension). One can also think of parameters like bordersasof=2010, projection=Robinson, micronations=circles etc.
This does sound as it it would save a lot of time. I'd like superclasses, too, like [all other countries not specified]=grey or [all other countries in Africa]=blue. I recently also had a problem with a map of a set of features which are small, but straddle the border between two large countries; I can imagine that being a problem here (for instance, suppose you wanted to show bilingualism rates along part of a border). It should be possible to select the coloured polygons included in the map by geographical area, not just by political subdivision. HLHJ (talk) 01:10, 31 October 2018 (UTC)[reply]
I love this idea. I recently made a couple of maps for the distribution of species and probably did it the hard way. I don't know enough about how SVG works to know if it would work for maps that show range of species (including migration and a fuzzy zone for rare occurrence areas) but I would welcome anything that would standardize the maps.PopularOutcast (talk) 00:33, 1 November 2018 (UTC)[reply]
This is a great idea! I would suggest being able to assign colors to certain geographical areas as well, making it easier for scenarios with fewer colors. I really hope this gets on the radar for the team, since personally I am tired of inconsistent and somewhat clunky maps that can be found on many pages. MSG17 (talk) 20:18, 5 November 2018 (UTC)[reply]
Hi, @Christallkeks: This is a really handy idea, and I'd love to see this go up in the wikis. Unfortunately, the feature is first blocked on the ability of the wikis to display SVG images as SVGs (rather than pngs), which is currently not available. Changing the way the wikis work to serve raw SVGs to the user is a huge task by itself that is outside the scope of what we can do as part of a wishlist item. This makes this proposal, unfortunately, fall in the same boat; the feature is too big for us to work on as part of the Wishlist. Thank you for your participation, MSchottlender-WMF (talk) 18:01, 15 November 2018 (UTC)[reply]
@MSchottlender-WMF: As I mentioned above, the graph extension offers an alternative to SVG, so to decline this proposal on the basis that an SVG implementation is unsuitable seems misguided. I've tweaked the proposal to suggest the graph extension should be used for the proposed solution instead of SVGs and believe it should be moved back to the active listings. Gareth (talk) 16:08, 16 November 2018 (UTC)[reply]
@Gareth: When we reviewed this in the wish triage, the team was very concerned about the scope of the wish and whether it will be feasible. However, if the intent is to try and come up with a way to make the Graph extension easier to use (rather than trusting people to understand json formats) we can probably look into that part. The voting has started already, but if the scope is clear to everyone that we will look into providing an easier way to do this with graphs (rather than SVGs) then I think you're right to say that the reason of pulling it out was incorrect. I am pulling this back into the wishlist. MSchottlender-WMF (talk) 20:53, 16 November 2018 (UTC)[reply]
@Christallkeks: So it turns out that the Graph extension already implemented this. I made a template on en:wiki (here) and on the MediaWiki site (here). Unintentionally, this template are pretty similar to one that was already on de:wiki (see here). So, the good news is that the capability is already there. The bad news is that there is still a lot to be desired, like better map data, being able to center the map in other places, being able expand the map like a picture or a Kartographer dynamic map to look at it closer, and historical borders. I'll see if there is anything to be done about that. MSG17 (talk) 18:43, 20 January 2019 (UTC)[reply]
Support Why limit that idea to maps? Having a way to "template-ify" .svg's would be useful for lots of things, starting with translating diagrams. Akela NDE (talk) 14:23, 25 November 2018 (UTC)[reply]
Problem: Although sheet music can already be embedded in articles to some extent, right now it's impossible to share digital sheet music as files on Commons. This limits the use of digital sheet music, which could otherwise be used to make synthesized audio files to compensate for the dearth of correctly-licensed recordings in Wikipedia articles and on other projects.
US copyright has prevented almost all audio created in the 20th century from going into the public domain,[note 1] and will continue to be similarly restrictive for years to come; and using public domain sheet music doesn't easily convey to (most of) those reading it how something actually sounds. At the same time, the MediaWiki Score extension can already render scores and play MIDI files from LilyPond source code.[note 2] However, LilyPond lacks a graphical editor and its scores can't be used through the MediaWiki file syntax without exporting to PDF or OGG. The open-source notation program MuseScore is feature-rich and has a graphical interface, as well as a large and active community at musescore.com (Alexa ranking of 3,417[note 3]),[note 4] but its files cannot be rendered in MediaWiki at all. Conversion to LilyPond format requires a two-step conversion through the MusicXML format.[note 5] However, both the MuseScore application and the MuseScore command line app can export MuseScore files to various file formats which can already be rendered or played by MediaWiki.[note 6]
Supporting MusicXML/MuseScore files on Commons would also potentially encourage MuseScore users to also upload scores to Commons,[note 7] and Commons would be able to take advantage of the large amount of transcribed public-domain sheet music that has already been uploaded to Musescore.com, including the verified and reviewed transcriptions that are being created as part of the OpenScore transcription project.[note 8] Because of Commons's more useful file categorization system and more stringent copyright enforcement, if Commons becomes another hub for MuseScore users it would also become easier for people to find digital sheet music and verify that a given score is in fact reusable for their purposes.
Who would benefit: Wikipedia readers, Wikisource readers and editors, Commons, LilyPond users, and the MuseScore community
Proposed solution: It would be beneficial for both readers and editors to allow notation files from Commons to be rendered and played.[note 9] This could be done by using the existing Score extension to render and synthesize the files,[note 10] by creating a new MediaWiki extension to allow them to be rendered separately,[note 11] by modifying the Media Viewer extension, or through a combination of those methods. There is an ongoing RfC at Commons to determine which file formats would be supported by Commons.[note 12][note 13]
Another improvement that could be considered would be to integrate a graphical notation editor into VisualEditor, since this would enable editors to create scores graphically without having to worry about file conversion issues.[note 14] This would probably require writing a graphical interface for LilyPond or improving an existing unofficial one.
Notes
↑Almost all audio created between 1923 and 1972 has a much longer copyright term than other works in the US due to being covered by state copyright law rather than federal copyright law until 2018, and the last recordings will only enter the public domain in 2067. See c:Commons:Hirtle chart#Sound recordings and w:en:Music Modernization Act.
↑LilyPond can play both MIDI files generated from the score itself and MIDI files uploaded to Commons.
↑As of 20 November 2018. This means that Alexa Internet measured it to be the 3,417th-most-popular website over the previous three months.
↑Musescore.com is possibly the most active community for uploading sheet music, although this is in no small part due to much of its content being arrangements and transcriptions of copyrighted works.
↑MuseScore files (.mscz) can be converted to MusicXML files (.mxl) in the MuseScore application, and vice versa; the open-source application Frescobaldi can convert MusicXML files to LilyPond files (.ly), but cannot do the reverse (although there are some conversion scripts around the internet). Most proprietary scorewriters, like Finale and Sibelius, can convert their files to the MusicXML format (or if not, there is usually a plugin or other program which can do that). None of these formats can be uploaded to Commons.
↑The ones most useful for Commons would be SVG, PNG, OGG and PDF.
↑Musescore.com has its own share of issues: users cannot update scores uploaded by others; its online player is unfortunately closed-source, unlike the MuseScore Windows/Mac/Linux application; and individual users can only upload five scores if they do not purchase a MuseScore Pro subscription. See the talk page for more background information.
↑It might also be possible to benefit from the score validation software that is being developed for that project.
↑This would probably be accomplished by modifying the file syntax to allow specifying whether a notation file is rendered as PDF, as audio, or both.
↑This would probably use the MuseScore app's command line to export files to PDF and OGG. It would be difficult to re-implement the entire MuseScore renderer, because the MuseScore format does not have a formal specification and is defined solely by the functionality of the application.
↑While it could be sufficient to only allow MusicXML uploads, it may be desirable to additionally allow MuseScore files to be uploaded. This is because MuseScore's import and export of MusicXML is not perfect, and if two users use MuseScore to contribute to the same file then it may be beneficial for them to avoid importing and exporting to edit the MuseScore source file.
↑Even if Community Tech doesn't have time to action this proposal, simply allowing uploads would allow musical notation files to be shared much more easily. For example, I've uploaded MuseScore exports to Commons before (such as File:Für Elise preview.svg), but have been unable to also upload the source file.
↑Since this would be LilyPond-based, presumably the original LilyPond and its users would also benefit from the new graphical editor's existence.
More comments:
Phabricator tickets:
phab:T208494 – Allow music scores to be uploaded to Wikimedia Commons (1 November 2018)
phab:T201637 – Support engraving of musical files on Wikimedia Commons (10 August 2018)
phab:T209695 – Playback for musical notation files hosted on Wikimedia Commons (16 November 2018)
phab:T183642 – Support MusicXML to Lilypond Conversion (24 December 2017)
phab:T49528 – Create a VisualEditor plugin tool to add/edit musical scores (23 April 2013)
I have no strong opinion on whether MuseScore files should be upload-able to the commons:, but it should not detract from the efforts being made for the usability of the music rendering that already exists in MediaWiki. The music notation code from any program should be paste-able in the <score tag, and that is achievable through the acceptance of MusicXML. Having phab:T49528 (extend VisualEditor for Score) as the Wishlist task would be the most meaningful addition to the extension (and that is too big for me by myself).
I am however concerned with the native MuseScore format. Without any formal specification and how it's prone to corruption and incompatibilities with anterior versions, it carries a big caution against using it anywhere else than natively supported (musescore.org/.com).
The size limit for LilyPond scores is basically the size limit of the Wikipedia page itself. The best solution for what is presented here is two-fold; support MusicXML (which would make import from a multitude of score-writers easier) and implement creating scores in VisualEditor. Supporting MuseScore is not a true solution to our problems. Ebe123 (Communication | Activity report) 18:23, 30 October 2018 (UTC)[reply]
@Ebe123: I have read that the MuseScore format is set to change again for 3.0, which is probably going to be released in early 2019. I agree it's problematic, but to me, the MuseScore end user, it outwardly appears that MuseScore is basically the only game in town because of its much larger community, which is why I suggested it over the LilyPond format, MusicXML or another format in the first place. (To others, noting that Ebe123 is also a LilyPond developer. I have nothing against him, of course, but it seems pertinent to note potential conflicts of interest, even if this isn't Wikipedia.)
I wouldn't mind if MusicXML was supported instead of the MuseScore format, but I've mostly only worked with MuseScore so it is more convenient for me personally to use MuseScore files, and some data (e.g. some text formatting, instrument "channel" switches which control audio output; visibility of staves) is lost when converting to MusicXML, although it's not clear to me whether this is an issue with MuseScore 2 or an issue with the standard itself. Jc86035 (talk) 18:49, 30 October 2018 (UTC)[reply]
I may be missing something here, but if a MuseScore GPL command-line app can convert MuseScore files to formats which can be uploaded to commons, why not just immediately auto-convert any MuseScore files uploaded? It seems that that would avoids problems with format changes. A see-as-it-plays viewer with a cursor would be great. I think Cmglee does such things in pure HTML, so it might be possible. HLHJ (talk) 00:45, 31 October 2018 (UTC)[reply]
@HLHJ: (Are you saying the files should be converted to PDF/OGG on upload, or they should be displayed as PDF/OGG?) The main purpose of allowing uploads of .mxl or .mscz files is that it would then be possible for other users to modify them as they please without having to transcribe the whole score again. The rendering/playback part of the proposal above is to internally convert the file to PDF and OGG (or, as proposed by Ebe123, to convert the whole file to LilyPond format and display it with the Score extension) and then display the file as both score and audio when the file syntax is used (or when it's used inside a <score> tag). Jc86035 (talk) 05:35, 31 October 2018 (UTC)[reply]
Converting it to Lilypond would seem to make more sense. MuseScore seems a bit proprietary for Commons; I'd also prefer a Visual Editor interface for Lilypond if it's the user interface that's the problem. HLHJ (talk) 05:33, 8 November 2018 (UTC)[reply]
Ouch, having a see-as-it-plays is hard even with JavaScript! It would also take lots of backend changes for things such as note spacings and tempo. Can't imagine anyone making one in plain HTML, nor would it be functional. Ebe123 (Communication | Activity report) 15:09, 31 October 2018 (UTC)[reply]
I'll take your word for it, Ebe123, I am not that familiar with Lilypond or HTML 5. How about implementing the cursor as a separate overlay? Could that be done with an automatically-generated SVG animation?
@Ebe123: I guess this might be a MuseScore bug, then? I might post on the MuseScore forum about this at some point, since the developers usually reply to posts and might know what's happening. Jc86035 (talk) 19:25, 31 October 2018 (UTC)[reply]
@Ebe123: By "corruption and incompatibilities with anterior versions", did you mean the errors when opening older (1.x and 0.x) scores in MuseScore 2, or something else? Jc86035 (talk) 08:26, 31 October 2018 (UTC)[reply]
Yes, and the fact that the files are easily corruptible (and that legal modifications are sometimes detected as corruption). Further because of the lack of a clear standard, there are incompatibilities within MuseScore within a version. Ebe123 (Communication | Activity report) 15:09, 31 October 2018 (UTC)[reply]
To bring back on track, I don't think this request is really about file support. The sentiment behind it is that LilyPond has a huge learning curve, and so we should make it easier to write music. This should be accomplished not by implementing a new program, but prioritizing graphical music notation to the VisualEditor team and Score extension maintainer (me). Ebe123 (Communication | Activity report) 15:09, 31 October 2018 (UTC)[reply]
@Ebe123: I think I agree with your characterization of this proposal, but I'm not totally sure. I agree that a lot more of this request is "allow .mxl/.mscz uploads" than it is "render .mxl/.mscz uploads", although the original point of asking for all of that together was that since the MuseScore command line can already export SVG and PDF it would hopefully not be particularly technically difficult to turn that functionality into a new extension (and using the MuseScore exporter itself would probably avoid some of the aforementioned issues).
(The main purposes of my requesting Commons uploads, to elaborate, are that without Commons uploading, because Wikipedia pages don't usually include the full text of works, full scores would almost certainly be relegated to Wikisource; it would be more difficult to use the score's audio on a page without the full score's code; and it would become more difficult to share/export/download scores.)
I generally agree with your concerns about MuseScore (perhaps particularly since it has been recently acquired, by Ultimate Guitar, and much of the development work is now being done by employees of that company). As the unaware end user, I can't really tell how much the issues matter, although they would definitely make developing an extension more difficult.
Would the VisualEditor integration mean that you/Community Tech/the VE team would be developing a full GUI for LilyPond, and then turning it into part of VisualEditor? Jc86035 (talk) 19:25, 31 October 2018 (UTC)[reply]
@Jc86035: The WMF is generally supportive of allowing and facilitating hosting of any file formats that the community is interested in (as long as they don't have serious security problems). Indeed, we generally leave the decisions about which file formats to accept to the communities themselves. In this case, there has never been a discussion on Commons (that I'm aware of) about whether the community would like to host MuseScore or MusicXML files. If it turns out the community objects for some reason, it would be pointless for the WMF to invest work in supporting those formats. Would you be willing to go ahead and start an RfC on Commons asking whether or not the community would like to host either or both of those file formats? Sorry I didn't suggest that earlier, but potential voters will want to know if there is community support before backing this, and the WMF will want to know before agreeing to do any work around this. Ryan Kaldari (WMF) (talk) 21:31, 15 November 2018 (UTC)[reply]
Comment "However, LilyPond lacks a graphical editor and its scores can't be used through the MediaWiki file syntax without exporting to PDF or OGG." Misleading. Its scores can be inputted directly into MediaWiki. File syntax is not necessary and is to be avoided. Further, any notation would have to be converted into an image or audio for display on the web... The Score extension is also about to change (gerrit:370209) to use SVG and MP3 is supported.
"However, both the MuseScore application and the MuseScore command line app can export MuseScore files to various file formats which can already be rendered or played by MediaWiki." More conversions? Also I see MuseScore renderings to be of lesser quality and not as feature-rich as LilyPond (and they removed the LY exporter!). Its GUI is its "attractor".
Supporting MusicXML in the extension is basically a "beginner" task :) I also think the MuseScore format is very poor and so we should focus on improving the LilyPond experience, although I can see why allowing MuseScore files may be wanted. Ebe123 (Communication | Activity report) 02:18, 19 November 2018 (UTC)[reply]
@Ebe123: Sorry, I seem to have written that sentence with the assumption that the reader knows that the Score extension supports LilyPond. Will fix. Quality is somewhat subjective, although LilyPond is unambiguously more customizable. Jc86035 (1) (talk) 16:26, 20 November 2018 (UTC)[reply]
“online WYSIWYG player/editor seems to be closed-source and freemium”: They use an OSS renderer internally on some places.
I’m also pretty sure that, if Wikimedia were to approach MuseScore/Ultimate Guitar, a Free solution could be found for code reuse suitable enough to make it usable here. (An online editor, though, is likely out of scope.) The profit model is to sustain development. Wikimedia adoption would rather drive more people to use it, so I’d think that would be more welcome. The MuseScore developers are very approachable and like the Free Software scene.
“I assume that it is also higher-bandwidth than the markup alternatives”: no. MuseScore files come in two flavours. *.mscx and *.mscz. The latter is the default, and it’s a PKZIP container with the mscx in it as well as any images etc. embedded into the score. The mscx is XML and comparable to MusicXML, but in my personal experience, MusicXML is more verbose. (MusicXML also has a compressed container format, *.mxl, but that’s rarely used.) I keep all my own scores as *.mscx in git and just batch-convert to other formats occasionally, and have written an MML to MusicXML exporter, so I have experience with both formats.
*online visual editor and playback software exists, including mobile version, but is proprietary; would have to either duplicate and compete, or partly rely on third-party freemium service
*browser-based, fast, wide and growing range of music cultures (including historic ones) encodable
*does not do really sophisticated engraving (making pretty scores for print)
*should be easiest, as open-source software exists, browser-based, SVG output (not sure if it does visual editing or just rapid previews)
*non-academic users
I see that MuseScore is heavily involved in MNX development;[1] more MEI-focussed groups, including LilyPond, are not. MuseScore is also ably represented here on the Mediawikis by Peter Jonas (shoogle). Perhaps someone might also contact the LilyPond devs and MEI devs ask them to participate in this discussion, so we can get a broad range of viewpoints? HLHJ (talk) 04:06, 23 November 2018 (UTC)[reply]
This discussion is continuing at the RfC, with useful comments from format developers. Comments from Mediawiki developers and other community members are also welcome. HLHJ (talk) 02:47, 29 November 2018 (UTC)[reply]
Partial support; I support LilyPond and MusicXML hosting, but not MuseScore hosting. I'd support conversion of MuseScore uploads. Reasons per my comments on the RfC. I support a Visual Editor plugin for editing music markups and a Commons score player. HLHJ (talk) 04:13, 18 November 2018 (UTC)[reply]
Support Could facilitate what I'd ultimately like to see happen with video: having an archive of free-use music available to use as scores, either by performing it themselves or attaching existing MIDIs to their videos. Daniel Case (talk) 23:06, 28 November 2018 (UTC)[reply]
Support Liuxinyu970226 (talk) 09:27, 17 November 2018 (UTC)
The interior of the Chapel Royal in Dublin Castle.
image from the museum
cropped image of Rivomarginella electrum
_(14593986718).jpg)
_-_Marginellidae_-_Mollusc_shell.jpeg)
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._-_Louvre_779.jpg)
_-_Louvre_779_-_Detail_(eyes).jpg)
_-_Louvre_779_-_Detail_(hands).jpg)
Oppose I think this issue, which I would agree is an important one, should be dealt with in the context of IIIF support by Wikimedia Commons. Beat Estermann (talk) 17:01, 18 November 2018 (UTC)
Comment Added the phabricator task for moving the MIDI to OGG (sound) conversion to TimedMediaHandler, which is used for videos and audio on Wikimedia. This is important so that we aren't bound to using the Score workaround, and so is the cornerstone of this proposal. Another task could be created for it to be automatized for all MIDI files in presentation. Ebe123 (Communication | Activity report) 01:50, 19 November 2018 (UTC)
Partial support; I support automatically adding a Synthlisten template to each MIDI file page; I do not support removing access to the MIDI files as MIDIs. HLHJ (talk) 04:20, 18 November 2018 (UTC)
Strong oppose ShakespeareFan00 (talk) 22:06, 25 November 2018 (UTC) At least until WMF legal had a chance to fully review what changes Article 13 and it's equivalents will mean in terms of the ability of WMF project to host certain types of content. ShakespeareFan00 (talk) 22:06, 25 November 2018 (UTC)
.svg)
.svg)
.svg)
.svg){kind=link}
