Wikimedia Commons

Commons:Village pump/Proposals/Archive/2018/11

< Commons:Village pump‎ | Proposals

Policy proposal concerning edited images

 
Example: source original & result of manipulation

Following a discussion (in Dutch) in De Kroeg, I'd like to make a proposal for a policy change, stating that user edited images from an external source should always be accompanied by a message, either in template or words, that the file consists of an image that is an edited form of the image the given source provided.

The discussion was raised by myself, after I found that a user was (and is) repeatedly and without exception uploading pictures of artworks, which are heavily (although some might say slightly, or not even notice a difference at all) edited images that originate most often from renowned museums, auction houses and other art institutes. By uploading the edited image, and not the original from the source, the impression cannot but be brought into existence, that the uploaded image equals the image from the source given, if any message on the editing done is lacking. Such a way of operating, in my opinion, is descrediting the source, discrediting Commons as well, and is deceiving a possible audience. The user around whom this proposal – that transcends the particular case – is made, has been requested by multiple users to a.) upload the source original as well, and b.) add a retouched-template to the description (which in my view should precede any other file information), but he refuses to do so and there seems to be no way to correct him.

Resume: add to the policy of Wikimedia Commons an obligation for users to state that a file, if indeed so, is an edited version of the file provided by an external source, so that violations of this kind can be tackled. Jürgen Eissink (talk) 19:33, 1 November 2018 (UTC).

I support in general. However: 1) We need to explicitly allow lossless transformations. I always perform lossless optimisations of files before uploading them here. This does no harm except saving Commons some space and traffic. 2) No user should ever be banned from contributing just for not providing such notices. It would be a shame to start losing contributors just because they forgot to write something about the file. I agree that this can be ascertained when a user is up for getting adminship privileges or somesuch. 3) A user can and should be allowed to contribute without the requirement to jump through several hurdles and having to learn policies before the first upload. We are a community, but sometimes I just want to upload something without having to read guidelines and notices about what I am suppose to say while simply trying my best to help out the project. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 20:07, 1 November 2018 (UTC)
I agree fully. The proposal is meant to deal with the purposeful visible violation of image integrity as related to the often unique source. Jürgen Eissink (talk) 20:28, 1 November 2018 (UTC).
  Support per what I wrote earlier: Commons:Village pump/Archive/2018/10#Retouched files. Also agree with Gone Postal: this proposal should not be used to bully new users, only those who know full well what they are doing. - Alexis Jazz ping plz 20:48, 1 November 2018 (UTC)
It shouln't bully any user. Ymnes (talk) 20:53, 1 November 2018 (UTC)
That's a matter of choice of words. The user who triggered this proposal will probably consider this bullying. Just like Sol-lol will consider it bullying whenever we delete their copyvios and many other users think we are bullying them when we delete their fair use material. Considering we probably won't ban anyone over this, the user who triggered this may well end up collecting dozens if not hundreds of warnings. We can only hope that at some point this will annoy him enough to change his behavior. - Alexis Jazz ping plz 21:21, 1 November 2018 (UTC)
One or two warnings, otherwise a block sanction. We have to think about the relation with institutions that are more or less suppliers: it's one thing to rip an image, it's quite a different thing to rape a picture and pretend it's a source original. In my view we have a moral obligation to protect the source in this respect. Jürgen Eissink (talk) 21:31, 1 November 2018 (UTC).
As I have stated above, I strongly oppose any sort of blocking for this reason. Just because something annoys you does not mean that the fault lies completely with another person. We already have a huge problems with admins using 'warning' language as if that's a normal conversation only to then coward away saying "it was only a warning", we should not make a problem worse! ℺ Gone Postal (〠 ✉ • ✍ ⏿) 21:56, 1 November 2018 (UTC)
I must have misunderstood, I thought you meant no banning for forgetting something, and no harsh treatment of new users. My proposal concerns repeated behaviour on a larger scale, and not because it annoys me, but because I think it is wrong to mess with sourced material without mentioning. A warning can only be a warning if consequences may follow. Jürgen Eissink (talk) 22:08, 1 November 2018 (UTC).
Just imagine you find a devaluated, or at least revaluated, picture attributed to your institution, an institution that has a good name for it's conscientious representation of art: how would you feel, and how would you think about Wikimedia Commons? And only because some user refuses to add a template, which would not make the adjustments any different, but would at least justify the claims made. Jürgen Eissink (talk) 22:26, 1 November 2018 (UTC).
Trying to understand just what this means: if we have a low-res JPEG version of a PD photo, and someone goes to a third-party site and obtains a high-res TIFF, converts that to a better JPEG, uploads that, and overwrites the low-res JPEG, are we saying that if they don't make it absolutely clear that they did exactly that then they would be considered in violation? - Jmabel ! talk 22:59, 1 November 2018 (UTC)
Thanks for asking. I see that my proposal, which by the way does not contain a final draft for a policy change, is not as clear as I hoped it would be. The proposal should apply only to the recolouring of pictures of works of art and other, comparable intentional manipulations to such degree that the picture is undeniably estranged from it's source, without mentioning so. I don't consider format convertions manipulations as such. (I added an example.) Jürgen Eissink (talk) 23:20, 1 November 2018 (UTC).
Examples by exaggeration are this and this – on each the left to be seen as the source original and the right as the manipulated upload to Commons, while maintaining that the source given has anything to do with or should even be responsible for the uploaded piece. The example given above to me is of the same nature. Jürgen Eissink (talk) 00:10, 2 November 2018 (UTC).
Would «"trivial removal of watermarks over white background" or "adjusting contrast in black&white cartoons" before uploading» be explicitly allowed then? Anyway, I'm with Gone Postal: One or two warnings, otherwise a block sanction seems a bit ...harsh. Strakhov (talk) 00:25, 2 November 2018 (UTC)
Removal of watermarks and contrast adjusting to me or by all means improvements, and therefore off course allowed, if it doesn't alter the meaning of the represented image. I can't see how a warning can be given if there would be no possible consequences – what's the point of rules if they are not maintained? Jürgen Eissink (talk) 00:47, 2 November 2018 (UTC).
To be extra clear: if you make a picture of a work of art, you can adjust and manipulate that picture however you like, without mentioning that your picture was manipulated: it's your picture. But if you adjust a picture of an artwork that somebody else took, you should be very carefull with manipulations. The given example is an indication of what, according to me, should definitely not be allowed without clearly stating the manipulation on the file page. you cannot just pretend the source to be responsible for a heavily changed upload. Jürgen Eissink (talk) 00:57, 2 November 2018 (UTC).
  Support; if anyone uploads a derivative of a third-party work—especially wherever irreversible operations are applied—then they must obviously declare that the uploaded file is derived from certain source, and isn’t identical to that source. Incnis Mrsi (talk) 17:00, 2 November 2018 (UTC)
  •   Comment This seems, currently, to be an over-engineered solution to fix a well discussed problem with one user: Jan Arkesteijn. Have a look at AN/U archives and feel free to open up another topic on this user to get him blocked. IMO Jan Arkesteijn has long passed the point of community patience with him overwriting files with altered files, and yes, modifying professionally made archive images without declaring so. If you can convince me that this is a widespread problem from other users, then it is worth discussion. But this is a simple matter of dishonesty, and we don't really need policy to declare that dishonesty is wrong and you could be blocked for it. -- Colin (talk) 12:02, 4 November 2018 (UTC)
    • I completely disagree. At this moment the user is actually doing nothing wrong. Somebody may dislike what they are doing but that is a problem with their dislike. The appropriate solution is to try to find a common ground. Btw, I do hope that this individual was made aware of what is happening and this is not a witch hunt. I do now agree with the proposal, but I will oppose any sort of "action" taken against a contributor. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 12:44, 4 November 2018 (UTC)
      • (after edit conflict)(Answer to Colin) In the earlier discussion in the Dutch De Kroeg many experienced (in time at least) users convinced me it's a shame but there is nothing we can do about it, and that's why I came up with this proposal. Policy could prevent any future cases as well, but my priority now is indeed stopping Arkesteijn, not for personal vendetta, but because I deeply think his actions are wrong. I am not familiar with AN/U and I don't know what you mean by it or where to look for such archive, nor how and where to start a topic on it – I would probably do such, if this policy proposal does not reach an accepted form, which to me still seems the best option: it would be a concrete realization of the demand for honest interaction with source material that is implicit in nearly all licenses summed up below. Jürgen Eissink (talk) 12:54, 4 November 2018 (UTC).
      • This isn't like/dislike. This user habitually uploads images and claims they are sourced from the given address, when in fact they are his own artistic modification of an original. Also engages in overwriting files leaving the source declaration untouched and now incorrect. His interpretation of "upload another version of this file" is "upload a different photo of this work of art". He's just out and out dishonest about sourcing, never mind the problem the above policy proposal seeks to change. He doesn't have any respect for the original archive or the need for an honest transfer here. I wouldn't have any problems if he uploaded a "... edited by Jan Arkesteijn.jpg" version but then that wouldn't be so simple to slip into n Wikipedia articles without anyone noticing. We should create policy to deal with wide problems, not one user. Honesty is a basic requirement for human interaction, I really don't see why we need a policy that says "you need to be honest when doing X". Put another way, is there any action in File space where one could be dishonest and that be acceptable?
Jürgen here is Commons:Administrators' noticeboard, there is a search box. I don't think the licence consideration below helps because nearly all these images are public domain. Even for CC works, the edit history is considered enough, as there is no requirement on any of us to leave an edit summary when editing. I know that that isn't best practice, but I don't think legal documents help. -- Colin (talk) 13:09, 4 November 2018 (UTC)
Now I get the impression that you don't understand the proposal, that precisely intends to stick the obligation to mention made alterations to PD imagery as well. It's a strange argument to say that you oppose the proposal because there are no requirements right now that equal those that the proposal seeks to implement. Jürgen Eissink (talk) 13:19, 4 November 2018 (UTC).
Jürgen, I only mentioned licences because you did. They are, IMO, beside the point. I haven't "opposed" the proposal, but I don't think it will gain sufficient community support unless you can demonstrate that it solves a wide problem with many users. Currently the only user this affects is heading towards an indef block. -- Colin (talk) 16:50, 4 November 2018 (UTC)
Addendum Based on past problematic cases, I suggest that special guidelines apply for professional photographs such as those from GLAM collections. In all cases the verifiably sourced original should be uploaded unchanged with their original EXIF data. Even in necessary cases where the image has to be cropped or rotated to be of realistic educational value, the original should be uploaded as the initial version so that even if the source goes offline, verification is easily done by any reader or reuser. In cases of digital repair, such as removing distracting noise or scratches from old photographs, the original should be kept as a separate file. Where this does not happen, other users should be supported/encouraged to revert, overwrite, or split file history, so that the verifiable original is always available. The one acceptable rationale to not do this is copyright, such as a modern photograph of a public domain painting where a complex frame is included, and must be cropped out to avoid the photograph having a valid independent claim of copyright. --Fæ (talk) 10:22, 10 November 2018 (UTC)
That more or less equals the proposal I meant to make. The case COM:ANU#Jan Arkesteijn – started by Jeff G. and developed by many others, most notabily you – has however shown, I think, that Commons:Project scope (which to me seems sort of the constitution of Commons) as a policy is pretty well suited to tackle cases like that. Given the precedent (was it?), one should not in the future hesitate to use it as the official policy that it is. That said, it might be good to abstract from it a guideline for the special purpose, to make it more convenient to act quick. Jürgen Eissink (talk) 19:20, 10 November 2018 (UTC).
  •   Oppose unless the scope of the proposal (colour paintings, black&white photos, black&white scans, tone, contrast, brightness, watermark removal, meaningless side-text removal after a crop, how and where changes should be noted...) and retroactivity (or the lack of it) are clearly determined. Strakhov (talk) 12:35, 6 November 2018 (UTC)
I often upload black and white scans of covers of old periodicals in the public domain (and a little watermark in a corner), and asides removing the watermark I sometimes change a bit the contrast and brightness. Uploading always the "original" scan with the watermark included and after that "the amateur modification" in a separate file when you have the source to check the "original image" I think it's some kind of "not-truth-paranoia". Strakhov (talk) 12:50, 6 November 2018 (UTC)
Don't know. After all, all this is summarized in

In general avoid changing the colour of paintings! even if they are in the public domain! the painter would not approve that!

When it comes to images with CC BY or CC BY-SA licenses please do not forget to mention your changes! After all... it's required by license!

I could agree with that. And please remember: Commons is, in fact, an amateur repository. We are not the NASA, so I'd advise to chill out ...about a low-resolution face screenshooted from youtube being a bit more yellow. Strakhov (talk) 13:44, 6 November 2018 (UTC)
I am glad to find that your opinion on the dehumanizing edit tactics of Arkesteijn doesn't seem to be widely shared. Jürgen Eissink (talk) 13:51, 6 November 2018 (UTC).
Well I'm not glad seeing contributors repeatedly dehumanizing other contributors with harsh words such as "fake", "vandalism", "falsification" in these threads. I understand the issue with Jan (specially if they were told to not do that), but I would try to assume some good faith. Cheers. Strakhov (talk) 14:01, 6 November 2018 (UTC)
because you are apparently asumming Jan changed a bit the colour of this photo to discredit and dehumanize Ellie Lust (?)... I do not know, it's a longshot. Occam's Razor would tell me he just thought the image looked better that way. Strakhov (talk) 14:19, 6 November 2018 (UTC)
Changing the colour of the eyes, giving the skin a greyish teint as to appaer anemic... I assume you have not been able to appreciate different earlier discussions in Dutch, where Arkesteijn motivates his actions and point of view: he alteres images for "illustration purposes", to undo "probable aging and contamination of the varnish layer"; he finds "many images in raw form are unsuitable for publication" (mind you: we are speaking about faithfull reproductions of artworks by renowned institutes, that own the artworks, as published on their sites); his opinion is that if he is to be adressed about his editing, one should also be adressing "editorials of newspapers and magazines because they change images to make them suitable for publication" too; etc. etc. Assuming good faith is a point long passed, since Arkesteijn has been asked by a multitude of users to at least denote his uploads as retouched and to upload the original as well, which he just keeps refusing. Jürgen Eissink (talk) 14:57, 6 November 2018 (UTC).

I'm gonna tell you a tale.

  • 01:33 17 sep 2017 I uploaded this pic from here, Apparently I forgot to give the url (which I understand is not explicitly needed when the image is PD and data on original publication is added). I removed a bottom watermark stating "Biblioteca Nacional de España" (a mark in a faithfull reproduction left by a renowned scanning institution, too bad the scan provided by them was that shitty!). I did not include a {{Retouched image}} tag because I thought it was a minor adjustement.
  • 18:54 15 sep 2018 I overwrote the scan after a year. The new one taken from Biblioteca Virtual de Prensa Histórica (BVPH). I removed a watermark from the Ministerio de Ciencia y Cultura and other one, older. I did link them and even respect their CC BY license (feel everyone free to remove that). Maybe I increased a bit the brightness/contrast.
  • 18:57 15 sep 2018 I cropped the image and removed part of the foonote «Notable periodista de ingenio chispeante» (linking the full file with {{Extracted from}}) for "infobox use".

BTW file history shows clearly there is no such thing as a "true" [sic] version of that cover.

I sincerely ask you: Is this the work of a professional offender? A falsificator? Fraud? Was the professional digitalisation (and watermark) of BVPH dishonored? Are watermarks and scan brightness from a public domain B&W scan something to be honored? Should I have uploaded two times that scan? (never heard of that policy yet, but who knows) If I did, glad to know. One way to honor them would have been, of course, not mentioning them at all. I can only tell you I acted inspired by my best faith. What I expect others give to me, I try to give to other people. Strakhov (talk) 19:04, 6 November 2018 (UTC)

Please deal with your own conscience yourself. I think I've made it clear why I made this proposal. Jürgen Eissink (talk) 19:19, 6 November 2018 (UTC).
I've made it clear why I opposed your proposal too. Because it is vague as [...]. Strakhov (talk) 19:34, 6 November 2018 (UTC)

Copyright implications support this proposal

I finally understood exactly what Jürgen Eissink is trying to propose. I would like to add something to the proposal. Technically not following this proposal is a copyright violation of many free licences. Please note that most free licences are terminated if you violate one of their terms. So technically if you upload somebody else's modified work without stating it's modified, it is a {{Copyvio}}. Below I list the licences that I use, feel free to list others, you think are of interest. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 06:38, 2 November 2018 (UTC)

Thank you so much. It is indeed the friction between the unasked for implication of a source with a derivated work that is not mentioned as such that I tried to address. Jürgen Eissink (talk) 12:22, 2 November 2018 (UTC).

Free Art Licence 1.3

http://artlibre.org/ 

2.2 LA LIBERTÉ DE DIFFUSER (INTERPRÉTER, REPRÉSENTER, DISTRIBUER).
Vous pouvez diffuser librement les copies de ces œuvres, modifiées ou non, quel que soit le support, quel que soit le lieu, à titre onéreux ou gratuit,
si vous respectez toutes les conditions suivantes :

1) joindre aux copies cette licence à l’identique ou indiquer précisément où se trouve la licence ;
2) indiquer au destinataire le nom de chaque auteur des originaux, y compris le vôtre si vous avez modifié l’œuvre ;
3) indiquer au destinataire où il pourrait avoir accès aux originaux (initiaux et/ou conséquents).

Les auteurs des originaux pourront, s’ils le souhaitent, vous autoriser à diffuser l’original dans les mêmes conditions que les copies.

It is the 2) that interests us: 

2) Indicate to the recipient the name of each author of the originals, including yours if you have modified the work;

GNU Free Document Licence 1.3

https://www.gnu.org/licenses/fdl.html

In 4. MODIFICATIONS 

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version,
together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they
release you from this requirement.

At first glance it may appear you can get away with not listing yourself, however: 

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

CC Share-Alike 1.0

https://creativecommons.org/licenses/sa/1.0/legalcode

This appears to be an exception. I cannot find anywhere in the licence a statement that you are required to state that the work is derivative.

There is: 

If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any reference
to such Licensor or the Original Author, as requested.

but this requires the original individual requesting to be disassociated with the derivative work.

Right, CC without attribution. Completely forgot that used to exist. - Alexis Jazz ping plz 16:05, 2 November 2018 (UTC)

CC BY and BY-SA 2.0

https://creativecommons.org/licenses/by/2.0/legalcode 

and in the case of a Derivative Work, a credit identifying the use of the Work in the Derivative Work (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). Such credit may be implemented in any reasonable manner; provided, however, that in the case of a Derivative Work or Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit.

CC BY and BY-SA 3.0

https://creativecommons.org/licenses/by/3.0/legalcode 

to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";

CC BY and BY-SA 4.0

https://creativecommons.org/licenses/by/4.0/legalcode 

You must: indicate if You modified the Licensed Material and retain an indication of any previous modifications;

GPL v2

https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt 

You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

GPL v3

https://www.gnu.org/licenses/gpl.html 

The work must carry prominent notices stating that you modified it, and giving a relevant date.

Change of proposal?

I'm uncertain as to what the above means for the proposal – could one of you elaborate, and maybe even state a proposal that can be voted over? Thanks in advance, Jürgen Eissink (talk) 16:47, 2 November 2018 (UTC).

  • Technically this means that if the file is reused under a free licence that requires you to notify of alterations and you failed to do so, then you are guilty of copyright infringement. However, under most free licences other people, who receive the work from the infringer are still ok. However, if it is Commons project that is not displaying the notice, then it is Commons that is infringing as well. … And I can continue with 'Howevers', however (no pun intended) if we introduce a message along the lines of «History of the work» rather than a single field date/author in the infobox, it will resolve all of the problems. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 08:45, 3 November 2018 (UTC)
 
Barbie doll
 
person
 
You look a little bleak.
 
I see you're feeling better.
 
She's about to turn into the hulk.. or maybe jaundice
 
Female hulk averted.
 
Oh noes, another one!
 
another hulk attack averted
 
maybe everyone suffers from jaundice
 
maybe not
 
too bright
 
better
  • Overwriting is a different issue. That already is visible and more or less preserves the history (the bigger problem is when people rather than creating a derivative create a completely different work and overwrite with that). The problem here is when a person has create a derivative and then uploaded as if it were original. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 06:58, 4 November 2018 (UTC)
  • @Gone Postal: Most of these are screenshots from YouTube videos that were altered without providing any indication of the fact they were made green. I've uploaded some proper images from the same source, largely redoing what this uploader did to provide this comparison. If only they could lay off the Photoshop, their contributions would be absolutely awesome. Sadly this uploader is convinced people must be made green and paintings must be blue, so sooner or later all the work they do has to be completely re-done.. what a waste. - Alexis Jazz ping plz 09:16, 4 November 2018 (UTC)
The question here could also be: why, for PD images, the need for a source if anyone can distort the source image without having to say so anyway? I think we must be better than that. Jürgen Eissink (talk) 11:54, 4 November 2018 (UTC).

Jan Arkesteijn's uploads are a problem. Making such severe, and sometimes destructive removal of detail from the originals and not saying so. Jürgen's concerns are valid here.   Support mirroring English Wikipedia's guideline here Wikipedia:en:Wikipedia:Manual_of_Style/Images#Editing_images and adjusting for Commons' use.--BevinKacon (talk) 13:26, 4 November 2018 (UTC)

The English guideline is nearly exactly what I was looking for! Thank you. To avoid misunderstandings there could be added that the guideline applies (of course) also to PD images. How could anyone not agree with such guideline? It would make it possible to, in this case, address Jan Arkesteijn properly.
If there would be no objections to adding such a guideline, how to proceed from here? Jürgen Eissink (talk) 13:43, 4 November 2018 (UTC).
That user had warned several times, and already in an edit restriction. I don't know anyone else behaving similarly. If true, a general guidelines is good. Jee 14:10, 4 November 2018 (UTC)
@Jürgen Eissink: create a page here (like COM:Mention your changes or come up with a better title), ask us here to look at it and fix issues, start new proposal to make that page policy. - Alexis Jazz ping plz 14:58, 4 November 2018 (UTC)
I   Support the creation of a page like Commons:Mention your changes and implementing such a guideline for users, we should be restricting problematic edits and not people, and this should also apply to these edits happening in the future by other users, honestly I thought that this discussion was mostly about the colourising of Nazi images (which I had no issue with as those images didn't overwrite the originals), but it's better to have derivatives uploaded as separate images and not used to overwrite the files, and unproductive changes to a(n existing) file simply for stylistic reasons (personal preferences) should always be discouraged. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:05, 10 November 2018 (UTC)
@Jürgen Eissink: you might be able to draw some inspiration from my essay COM:Colorization#A few things to consider. - Alexis Jazz ping plz 20:11, 10 November 2018 (UTC)
Wasn't this inspired the other way around by my conversations early september?  . Jürgen Eissink (talk) 20:16, 10 November 2018 (UTC).

PD Indonesia license tags renewal

Since 2014, Indonesia has changed It's copyright regulation from Law of the Republic of Indonesia No. 19, 2002, on Copyright to Law of the Republic of Indonesia No. 28, 2014, on Copyright. According to article number 124 of Law of the Republic of Indonesia No. 28 of September 16, 2002, on Copyright, At the time this Act comes into force, Act No. 19 of 2002 on Copyright (State Gazette of the Republic of Indonesia Year 2002 Number 85, Supplement to State Gazette of the Republic of Indonesia Number 4220) is revoked and declared invalid.

Here's the list of templates that are expired: Category: Expired PD Indonesia license tags

Here's the list of new templates and renewed templates:

  • Edit request:
    • If anyone could help me to grant me request or at least put the new edit text for this template, it would be very helpful.

When this finished, I hope we can use a bot to change earlier used template with the new ones we made.

Thank you.

--Hilmanasdf (talk) 17:57, 8 November 2018 (UTC)

Nice update, big thanks for your contributions.ReaperDawn 02:15, 9 November 2018 (UTC)
I'd like to complete the edit request concerning Template:PD-IDGov, but I am wondering if I may correct the English copyright law translation before introducing it to the template, as the translation contains a few grammatical errors. FYI, article 43 is the relevant one for PD-IDGov. --HyperGaruda (talk) 05:46, 9 November 2018 (UTC)
I found the official english version document from Directorate General of Republic of Indonesia Regulations website, which also make me want to revise the previous translation I quote from the previous source. I think you can also use it for the PD-IDGov revision. You can access it through this link. Thank you. — Preceding unsigned comment added by Hilmanasdf (talk • contribs) 07:52, 9 November 2018 (UTC)
You can access the English translation here. ReaperDawn 08:44, 9 November 2018 (UTC)
Thanks, Reaper! But what I actually need is the access to translate the Template:PD-IDGov template, haha. --Hilmanasdf (talk) 07:57, 12 November 2018 (UTC)
Also, PD-IDGov doesn’t quite cover 43 e (portraits of officials and national heroes) since the law implies that it doesn’t have to be published by the government - though I guess it’s almost the same but still. Juxlos (talk) 12:46, 11 November 2018 (UTC)
Yup, I guess that's why we should update the template with at least things mentioned in section (1) article 43. Thanks. --Hilmanasdf (talk) 07:56, 12 November 2018 (UTC)
Well, I proposed what to change here and here, but no reaction so far although it has been over a week. I suppose there are not many admins watching Category:Commons protected edit requests, looking at how long some edit requests have been left unanswered. --HyperGaruda (talk) 12:20, 18 November 2018 (UTC)

NOAA image

Can I upload this image: https://images.slideplayer.com/25/8065026/slides/slide_46.jpg

It appears to be from NOAA.

Its used here: https://slideplayer.com/slide/12928367/ (number 9)

and here: https://slideplayer.com/slide/8065026/ (number 46)

Here is NOAA's copyright notice: https://www.photolib.noaa.gov/about.html — Preceding unsigned comment added by Just granpa (talk • contribs) 23:24, 17 November 2018 (UTC)

@Just granpa: Yes, this should work. You can use {{PD-USGov-NOAA}} as a licence tag. By the way, next time please try asking questions like this at Commons:Village pump/Copyright. The "Proposals" board is for technical improvements, changes to community guidelines and such, but not for suggested uploads. De728631 (talk) 17:41, 18 November 2018 (UTC)
I went to copyright but I didn't see any button for starting a new discussion. I thought that was what this was for. Just granpa (talk) 21:22, 18 November 2018 (UTC)

Updating Template:Dont remove warnings

This thread at ANU most recently highlighted the incongruity between this template and Commons:Talk page guidelines, where the template warns users to "not remove legitimate warnings from your talk page", while the guideline simply recognizes the practice as discouraged, while explicitly allowed.

This seems to be a perennial issue. The template's talk page has threads about this very issue going back as far as 2007, and the template has been nominated for deletion twice in 2009 and 2013, with many of the keep !votes themselves observing that the wording was problematic and should be updated to better reflect actual community standards, rather than trying to make policy by fiat via template.

So I'd suggest we update the wording of the template, given that with the checkered history, we can predict with relative certainty this problem is going to come up again if left unaddressed. I propose we update the wording to the following:

català ∙ Deutsch ∙ English ∙ español ∙ français ∙ italiano ∙ magyar ∙ Nederlands ∙ polski ∙ português ∙ sicilianu ∙ slovenščina ∙ svenska ∙ suomi ∙ македонски ∙ русский ∙ українська ∙ 日本語 ∙ עברית ∙ العربية ∙ فارسی ∙ +/−

 
Hello. This is a reminder that removing legitimate warnings and notices from your talk page without addressing the identified issues is discouraged according to our community guidelines. Removing messages does not remove them from the page's history, and doing so is often seen as rude or hostile by the community. You are encouraged instead to archive past discussions. You can have this done automatically for you - simply place {{subst:User:MiszaBot/usertalksetup}} at the top of your user talk page and old messages will be archived after 1 month (see User:MiszaBot/usertalksetup for more details).
If you have received warnings for copyright issues please familiarize yourself with our policy on licensing. You can also ask for help at the village pump or the help desk if you need assistance.
Detailed changes

català ∙ Deutsch ∙ English ∙ español ∙ français ∙ italiano ∙ magyar ∙ Nederlands ∙ polski ∙ português ∙ sicilianu ∙ slovenščina ∙ svenska ∙ suomi ∙ македонски ∙ русский ∙ українська ∙ 日本語 ∙ עברית ∙ العربية ∙ فارسی ∙ +/−

 
Hello. This is a reminder for you to not remove that removing legitimate warnings and notices from your talk page without addressing the issues you received these warnings for identified issues is discouraged according to our community guidelines. Note that removing warnings from your talk page will Removing messages does not remove them from the page's history, and doing so is often seen as rude or hostile by the community. You are welcome to archive your talk page. You are encouraged instead to archive past discussions. You can have this done automatically for you - simply place {{subst:User:MiszaBot/usertalksetup}} at the top of your user talk page and old messages will be archived after 1 month (see User:MiszaBot/usertalksetup for more details).
Please read Commons:Licensing if you have received these warnings for copyright issues.If you have received warnings for copyright issues, please familiarize yourself with our policy on licensing. You can also ask for help at the village pump or the help desk if you need assistance.

This more closely follows the wording in the guideline, and also includes links to VPC and HD for users who may have questions but need assistance. The rest is comparatively minor tweaks in wording, in addition to piping the wikilinks, mostly because, in my personal opinion, we should be doing that anyway when dealing with newer users. GMGtalk 13:48, 6 November 2018 (UTC)

@GreenMeansGo: Perhaps we could expand it a little by adding "and notices" to form "warnings and notices" in two places?   — Jeff G. ツ please ping or talk to me 14:02, 6 November 2018 (UTC)
Why don't see split the difference in the interest of flow? Added "and notices" in the first instance, but then simply downgraded to the more generic "messages" in the second. GMGtalk 14:04, 6 November 2018 (UTC)
@GreenMeansGo: Thanks, that works.   — Jeff G. ツ please ping or talk to me 14:26, 6 November 2018 (UTC)
  •   Support.   — Jeff G. ツ please ping or talk to me 14:26, 6 November 2018 (UTC)
  •   Support I would have said "identified issues is strongly discouraged" but let's not sweat the small stuff. This is certainly an improvement. -- Sixflashphoto (talk) 21:21, 6 November 2018 (UTC)
  •   Support --Packa (talk) 21:34, 6 November 2018 (UTC)
  •   Delete I still see the wording of this template is not supported by any of our policies. Our "user talk page" policy is very brief. No wonder as people expect much freedom on handling it as it is not a serious business of others. The same in one of our sister project is more clear. "Although archiving is preferred, users may freely remove comments from their own talk pages. Users may also remove some content in archiving. The removal of a warning is taken as evidence that the warning has been read by the user." This is exactly the situation here too, and I see no reason to think other way. And if we read this which made some storm here too in the past, we can easily understand that a civilized community never wish to interact with a fellow using a Badge of shame. When we go through the history of this template, we can see several attempts to mark it as {{Deprecated}}. When we go through the talk page, we can see that Lar (one who created this) had a strong feeling that it should be deleted. In the deletion request, Denniss stated that "this template is typically only used for copyvio uploaders resistant to talk page notices and is used as a higher level warning". But it is nowhere documented and we have examples that this template is recently used on the talk page of very legitimate uses which is the immediate reason of this discussion. In my opinion, we work in several Wikimedia projects simultaneously, and having entirely contradicting behavioral policies in different project are difficult to remember and deal with. For all these reasons stated above, I will not support the use of this template. Jee 03:33, 7 November 2018 (UTC)
  •   Support, although I can't see that I often see this template being used. Often I see users who let a wall of warnings pile up, but honestly I think that there should be a special project to help educate users more on copyright rules and what applies to what (including geographically) and that these automated templates will probably get ignored because of their inpersonal nature, but I strongly encourage this form of archiving over the "archived into page history" "archiving". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:45, 7 November 2018 (UTC)
  •   Comment I agree with "discouraged" but have reservations about using this template where it may cause escalation. I have seen users blocked for repeatedly blanking warning notices from their talk pages. As per the guidelines, this may be discouraged, but should not be taken as so hostile as to warrant administrator action. So long as a notice can be presumed as read, there is no need to hound a user who may in truth be annoyed or confused by very large angry sounding notices. If anyone doubts the notices are understood, they can discuss and if necessary take the discussion to a noticeboard. --Fæ (talk) 12:13, 7 November 2018 (UTC)
  •   Delete per Jee. Agreeing to this wording is agreeing to it being used. Administrators are no different to other users except for some extra buttons, and any user may choose to edit their talk page, remove edits, refuse to engage with individuals as they see fit. I support a shift to the Wikipedia practice/viewpoint where removal of a notice or message is simply taken as acknowledgement that it has been read. If there are certain messages/templates that the community feels absolutely must be retained on talk pages (e.g. serious copyvio notices) then let's have a discussion about them. -- Colin (talk) 12:31, 7 November 2018 (UTC)
I'm fine having a discussion also about updating the guideline. In the meantime, this seems like a comparatively easy fix to at least bring the template and the existing guideline in line with one another. If some folks really are blocking users solely for removing talk page warnings (rather than for the reasons they're getting those warnings to begin with, like repeated copyvio), then I'd say they're out-of-bounds as far as existing policy goes.
Other than that, I'm not really sure I understand the relevance of Administrators are no different to other users. This is mostly to do with our copyvio and vandalism patrollers leaving a template that doesn't conform to existing guidelines. I'm not sure our administrators are really the ones doing most of the front-line patrolling in those areas. GMGtalk 13:37, 7 November 2018 (UTC)
GreenMeansGo, yes some admins have indeed blocked users simply for removing a talk page message (not even an official warning message). And community agreement on this template would be taken as de facto guideline that talk page messages must not be removed. While you may consider this template wrt copyvio/vandalism there are other admins who view anything they do and say as holy and requiring of obedient respect from the proles. -- Colin (talk) 11:53, 10 November 2018 (UTC)
@Colin: Such behavior is unprofessional.   — Jeff G. ツ please ping or talk to me 11:57, 10 November 2018 (UTC)
Jeff G., who's behaviour? The admin or the user being blocked? -- Colin (talk) 12:02, 10 November 2018 (UTC)
@Colin: The admin, of course.   — Jeff G. ツ please ping or talk to me 12:14, 10 November 2018 (UTC)
Well, I'd say that if we have admins and other experienced users who are misapplying current guidelines, that probably isn't helped by a template that itself misunderstands guidelines. Keeping in mind also that for many or even most users here, this isn't their home project. So it would maybe make even more sense to just take a template at its word, and assume that the community did its due diligence in making sure they two align.
But it's looking like the solution here is to 1) update the wording of the template, and then 2) immediately nominate it for deletion. If it survives deletion, then keep the updated wording, and if it don't then it don't. GMGtalk 12:22, 10 November 2018 (UTC)
  •   Support. Whatever our policy is, this is de facto policy. It can't be enforced, but users can be informed about our customs. This template can help with that. - Alexis Jazz ping plz 13:03, 7 November 2018 (UTC)
  •   Delete the entire template. "The removal of a warning is taken as evidence that the warning has been read by the user". Users should be discouraged from watching other users' talk pages. This will decrease a lot of drama and tensions. 4nn1l2 (talk) 15:38, 7 November 2018 (UTC)
    Exactly! Jee 15:55, 7 November 2018 (UTC)
  •   Delete the template and add to our guideline something in the kind "Removing legitimate warnings and notices from your talk page without addressing the identified issues is discouraged. Removing messages does not remove them from the page's history, and doing so is often seen as rude or hostile by the community. You are encouraged instead to archive past discussions. The removal of a warning is taken as evidence that the warning has been read by you." Christian Ferrer (talk) 17:33, 7 November 2018 (UTC)
  •   Delete the template, per Colin and Jkadavoor. "The removal of a warning is taken as evidence that the warning has been read by the user". -- Begoon 12:23, 8 November 2018 (UTC)
  •   Support Deleting it does not seems reasonable. --Steinsplitter (talk) 12:29, 8 November 2018 (UTC)
  • This is not a deletion discussion. To request it's deletion, please start a COM:DR discssion. Per policy it is not speedie-able, and the only other way to delete a page is after a deletion request discussion - something this venue is not. This dicussion is about chaning the wording of the template. --Jonatan Svensson Glad (talk) 13:32, 10 November 2018 (UTC)
As mentioned above, opining upon a wording change implies that using the template is ok, something which those in favour of deleting the template obviously do not believe. I see no problem with expressing that opinion here. Since no feasible changes to wording will fix the problem I cannot support or oppose them, as there is no wording I would support - the template should not be used. Supporting implies the template would then be ok, opposing implies there is other wording I might support - neither is true. Fiddling with the wording may actually encourage people to use this officiously offensive, bitey, big scary warning which is unsupported by policy, believing it to be "fixed" in some way, continuing to needlessly upset users and cause further issues such as those causing this discussion in the first place. I oppose that. I hope that's clearer.  . -- Begoon 10:01, 11 November 2018 (UTC)
  •   Oppose. I propose the following text: "Dear user, this is a reminder that you are in almost complete control over your user space. If anybody attempts to harass you for removing any templates or any other text from your user page, talk page, or their subpages, please report them to COM:ANU." ℺ Gone Postal (〠 ✉ • ✍ ⏿) 19:44, 10 November 2018 (UTC)
  •   Delete the template - Unblock requests aren't allowed to be deleted, Other than that you can add and remove anything else as you please. –Davey2010Talk 20:14, 10 November 2018 (UTC)
  •   Support.Vulphere 05:03, 11 November 2018 (UTC)
  •   Support I support the changes as it is less harsh than the current wording. However, I would be fine with deleting the template if it came to that. While archiving is preferred there is absolutely nothing wrong with just removing the section as it is still in the history. Warnings and such should never be used as a mark of shame that can never be removed. I take removal as an acknowledgement of the notice. If the behavior continues after the fact that just increases the likely of sanctions as, to me, they have acknowledged the problem and chose to ignore requests to change course. --Majora (talk) 04:01, 19 November 2018 (UTC)
  •   Support re-wording, but prefer   deletion, as per many others above. --El Grafo (talk) 13:27, 20 November 2018 (UTC)

A humble request to the editing community

  Since the voting phase of the Community Wishlist Survey 2019 has started, I would like to invite all interested editors (particularly those who edit from mobile devices) to vote for the proposal to add a revert functionality to the mobile interface, so that a strong message may be sent out to the Wikimedia Foundation and its employees to take its mobile user-base seriously and eventually bring the mobile interface at par with other major websites of the internet. Regards.FR30799386 (talk) 05:32, 19 November 2018 (UTC)

 

A mock-up of how the revert functionality may look on the mobile interface

— Preceding unsigned comment added by FR30799386 (talk • contribs) 05:32, 19 November 2018 (UTC)

@FR30799386: I've been pushing the Wikimedia Foundation to improve the mobile interface for quite some time to no avail, I hope that your proposal succeeds as the inability to undo edits using the mobile interface is something I run into seeing vandalism. Anyhow as I'm not allowed to vote I won't be able to help you, but you could alternatively open a Phabricator ticket. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:31, 21 November 2018 (UTC)

Templates Anonymous-EU and PD-France

I have been moving Anonymous-EU licences to PD-France for old French postcards.(see Category:Postcards of Ardèche) The 'Anonymous-EU' is included as one of the conditions for PD in France. I would like to see the same text used in Anonymous-EU, for considering the template PD-UK-unknown for files of UK origin. Later on, one can consider scripts to change french postcards with the licence Anonymous-EU to PD-France.Smiley.toerist (talk) 00:10, 25 November 2018 (UTC)

Create a Technical Village pump

COM:VPT is now open for business. --Majora (talk) 22:25, 28 November 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Currently there is no page called "Commons:Village pump/Technical even though there appears to be some demand for it, a lot of talk pages of tools seem to be unmonitored and often technical questions and/or requests seem to pop up here, at the help desk and at the regular village pump all the time, maybe creating a separate technical village pump could benefit users with more technical requests. This would also be easier for users who do have the technical expertise to help other people to only have to monitor a single place for technical questions. Often I see technical questions in the help desk go unanswered simply because that fortnight no technician bothered to check.

I think that the English-language Wikipedia also has one but I'm not certain. Is this viable? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:45, 23 October 2018 (UTC)

@Odysseus1479: Commons:Village pump/Copyright just has autotranslate templates on it. If this proposal has community support and someone could put those templates together and could set up the autoarchive system after its done, just designing the page Commons:Village pump/Technical wouldn't be that difficult. I don't think i'm missing a step other then implementation. Also I am going on the possibly wrong assumption that one could put together Template:Village pump/Technical/Header put it into a page and you don't have to do each language template individually. -- Sixflashphoto (talk) 16:30, 27 October 2018 (UTC)

  Done The base has been created at Commons:Village pump/Technical and the header template now exists at {{Village pump/Technical/Header}}. The header has been marked for translation. I have yet to add the page to the {{Community tabs}} since I'm not really sure I should do so until it is at least translated a little bit. However, I can do so if that is what people want. --Majora (talk) 22:04, 27 November 2018 (UTC)

@Majora: Thank you. @George Ho made it a requirement in Template:Community tabs/core, resulting in "• [[{{{link-3.3}}}|{{{tab-3.3}}}]]" ugliness in many languages. I made it optional for not yet fully translated languages. Please at least add "| tab-3.3 = technical" and "| link-3.3 = Commons:Village pump/Technical" to {{Community tabs/en}}.   — Jeff G. ツ please ping or talk to me 11:48, 28 November 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Musical notation files

Should MusicXML, MuseScore or LilyPond files be allowed to be uploaded to Commons? Jc86035 (talk) 10:55, 16 November 2018 (UTC)

(Note: MEI was added after the RfC opened. MNX is presumably not an option because it doesn't exist yet.) Jc86035 (talk) 10:14, 26 November 2018 (UTC)

Background

It may be desirable to integrate musical notation files into MediaWiki, most likely by allowing their display as thumbnails and possibly allowing audio playback from them. In November I made a Community Wishlist Survey proposal to propose the technical development of such capability. Even though the proposal has not succeeded, it may still be advantageous to host these files on Commons without using them directly in other projects.

The benefits of having notation files (as opposed to PDFs/images or audio) include their being machine-readable and that they can be converted to audio and more easily reformatted and edited. The benefits of uploading them to Commons, instead of using the notation directly in articles (with the Score extension), include easier transclusion and sharing and better visibility.

The three file formats each have advantages and disadvantages, and it may be thus beneficial for Commons to support more than one format (or even all three of them). LilyPond and MuseScore are the primary libre notation software programs, although they are quite different in their approaches.

  • MusicXML (.mxl) is an open standard codified by a W3C community group (although not an official W3C standard), and export and import to it are widely supported by both proprietary and libre notation programs; but most programs have better support for their own notation file type than for MusicXML, resulting in minor display issues upon import (as well as playback issues for MuseScore specifically). Some editors may wish to upload the source file rather than be forced to perform a conversion. The MusicXML format specification is no longer being actively developed (although not abandoned) as the W3C community group have decided to focus on a new format called MNX, which is intended to overcome many of MusicXML's limitations. However, MNX is still at the early development stage and is not ready for implementation.
  • MuseScore (.mscz) is quite versatile and is focused on MIDI-style playback as well as score display, and the software is a graphical scorewriter (like Sibelius and Finale). It is possibly the world's most popular scorewriter, surpassing even Sibelius and Finale. However, in the past it has had compatibility issues between versions (related to opening files created with older versions of the software), and the file format is defined entirely by the software's source code (which is open source). Due to its lack of a separate specification, a full MediaWiki integration with editing capabilities would potentially be more difficult than for MusicXML. However, a MuseScore viewer would be simple to create using MuseScore's existing open source renderer to generate synced SVGs and audio files on the backend.
  • LilyPond (.ly) is already supported in MediaWiki as mw:Extension:Score. Due to being much like a programming language, it is easy to write as source code, but more difficult to learn than MuseScore for most people. It does not have a complete GUI, although Frescobaldi (advanced code editor) and Denemo (limited GUI) are helpful in this regard. LilyPond is the only major scorewriter not to support exporting to MusicXML, so files created with LilyPond cannot be opened in other score editors, such as MuseScore, Finale or Sibelius.
  • MEI (.mei) is a community-developed application-agnostic format. It was developed as a comprehensive format for encoding all kinds of music notation (not just common-practice, post-1750 notation), so it supports other notation styles (tablature, mensural, neumes). It also supports a wide range of editorial features (multiple source readings, annotating corrections, additions, etc.). As a result, it is quite an extensive and, perhaps, complex specification. MEI lacks widespread desktop notation editor support, but it is supported by a JavaScript-based engraver, Verovio. Verovio supports MEI playback (MIDI), PDF export, and can also render MusicXML, **kern, and Plaine & Easie notation. — Preceding unsigned comment added by Ahankins (talk • contribs) 12:56, 28 November 2018 (UTC)

MIDI, incidentally, is already supported as a file format on Commons. However, playback requires passing the files through the Score extension, and MIDI is audio-only and may not render very nicely.

Survey: Allow MusicXML files on Commons

Survey: Allow MuseScore files on Commons

Survey: Allow LilyPond files on Commons

Survey: MEI/Verovio

  •   Support as belated proposer (see table in discussion below). This format would be a tie to a whole additional community of users, academics (who work a lot on public domain music, and might even have funding). HLHJ (talk) 05:15, 23 November 2018 (UTC)
  •   Support.   — Jeff G. ツ please ping or talk to me 05:31, 23 November 2018 (UTC)
  •   Support Abzeronow (talk) 16:26, 23 November 2018 (UTC)
  •   Support. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:06, 24 November 2018 (UTC)
  •   Neutral; although I would be fine with it I would be worried that not a lot of people would actually use it (and it would require more extra work to integrate it into MediaWiki, seeing as the MusicXML converter is still in development). Also, given the number of file formats, this. Jc86035 (talk) 13:24, 24 November 2018 (UTC) (edited 13:40, 26 November 2018 (UTC))
  •   Support We need to open up to many more file types. —Justin (koavf)❤T☮C☺M☯ 22:55, 26 November 2018 (UTC)
  •   Support Long-term I think MEI will be a better content format for Commons than MusicXML, MNX, MuseScore, or LilyPond, because the academics and musicologists who are building MEI have similar goals to express music notation and works built on music notation. Short-term, there is the problem that MEI doesn't have much support from notation editors. That will change. JimDeLaHunt (talk) 03:27, 27 November 2018 (UTC)
  •   Support A number of emerging digital editions have chosen MEI as their file format for long-term preservation and new digital editions. For example, it is in use by the Mozarteum, The Bach Archiv, the Beethoven House Bonn, and a number of others. MEI is actively developed (4.0.0 released this fall) with a broad community behind it. It has elected governance[1], supports an annual conference[2], and is provided under a liberal license[3].--Ahankins (talk) 23:14, 27 November 2018 (UTC)
  •   Oppose MEI is a specialized format highly tailored for music research. Its intended audience of music historians, librarians, and theorists does not appear to match the Wikimedia audience very well. Multiple formats likely makes things more difficult for both users and implementers than choosing one standard format. Mdgood (talk) 15:57, 27 November 2018 (UTC)
    • I'm not sure what to make about this -- MEI can be used for specialized tasks, but only because it has the features to support them. It also has bog-standard music encoding features. So the fact that it can be used for more than simple encodings, but that it still *can* do simple encodings, doesn't really seem to be a reason to oppose it? --Ahankins (talk) 23:21, 27 November 2018 (UTC)
    • Commons loves GLAM, and scholars! Our audience is anyone interested in disseminating knowledge. HLHJ (talk) 04:03, 28 November 2018 (UTC)
    • The problem is that MEI is not designed for anyone other than music researchers. It was created as a specialized format for music scholars without compromise for other needs. That is totally appropriate but has also made it notoriously difficult to implement in software. MusicXML has a much better track record of collaboration and support for different musical communities. And again, I think you will find that multiple formats make things more difficult and confusing for everyone, not easier. Mdgood (talk) 19:48, 28 November 2018 (UTC)
    • It's not true that MEI is designed for scholars only – it just offers multiple perspectives on music notation, including, but clearly not limited to musicological ones. Feature-wise, it's a superset of MusicXML, with lots of additional aspects for all kinds of needs (syncing with AV files, anyone?). For Commons, the featureset of MusicXML is probably sufficient, but MEI is currently working on a customization / profile / subset called "MEI Basic", which allows full roundtripping between MusicXML and MEI. It's also not true that there is no data available in MEI – for instance, all of Mozart is going to be published as MEI files by the Mozarteum in Salzburg over the next year(s), and the Bach-Archiv offers the catalogue of Bach Digital as MEI (metadata). Sure, the number of files is smaller than with MusicXML, but those files are often of very high quality and free to use. (disclaimer: I'm deeply involved with MEI) Jkepper (talk) 22:35, 28 November 2018 (UTC)
  •   Support MEI is a well documented, open standard, aiming at supporting all sorts of notational features. --Stadlerpeter (talk) 07:17, 28 November 2018 (UTC)
  •   Support MEI and Verovio are both developed with long-term perpectives in mind, and for that reason the seem quite appropriate for Commons - disclamer: developer of Verovio. --Lpugin (talk) 14:16, 28 November 2018 (UTC)
  •   Support MEI supports very rich metadata, so besides rendering scores, it could feed the metadata sections of Mediawiki (although I don't know how that works). There is also an API (EMA [4]) in the MEI world (though not technically restricted to MEI) that allows to identify sections of an MEI file. This could be very useful to have full encodings stored on Commons, and only specific snippets shown in articles. (disclaimer: deeply involved in MEI…) Jkepper (talk) 22:35, 28 November 2018 (UTC)
  •   Support It includes modules for neumes and mensural notation, so the supported time period covers about 1000 years of music history. Possibly useful if the scope of Commons is not to be restricted on notation betwenn 1600 and 1950 only --KriSte Mühe (talk) 22:03, 5 December 2018 (UTC)

Survey: Braille music

Survey: ABC notation

Discussion

Consensus summary table

This table attempts to summarise a community consensus from the discussion below. Please edit and improve.

Format Advantages Disadvantages Technical difficulty Lacks
MusicXML
  • common interchange standard, widely supported by notation editors and processing software
  • large user community and W3C Community Group
  • proven ability to represent advanced level notation
  • uses XML standards (XSD and DTD validation, XSLT)
  • different editors export it differently
  • XML standard implementation is not complete (no 'xml:id' support, no namespace)
  • can be imported by almost any player or notation editor
  • can be displayed in browser by Verovio (see example)
  • plug-and-play open source web renderer (many web renderers exist, but they are proprietary; LGPL Verovio (below) has beta rendering[5])
MEI
  • wide and growing range of music cultures (including historic ones) encodable
  • demonstrated ability to represent advanced level notation
  • uses XML standards extensively, making it suitable for Linked Data applications, schema validation, XPath/XSLT, etc.
  • focuses on 'semantic' markup of notation (i.e., what the symbols mean) rather than visual markup (i.e., what the score looks like)
  • active international community; elected governance
  • really sophisticated engraving (making pretty scores for print) requires custom software integration (Verovio)
  • difficult for spec-complete software implementations unless subsetted as in Verovio or MEI Basic (under development)
  • focus on semantic markup makes it more difficult to encode precise engraving (e.g., 'this slur must be so far past this note head')
  • Verovio rendering library might be a useful free-libre component
  • liberally-licensed formal specification and source code
  • (With Verovio) client-side rendering means less ongoing server-side rendering software support necessary
  • (With Verovio) SVG output can be used for dynamic highlighting and interaction with rendered scores (CSS, JavaScript, XPath)
  • extensive software editor support (programs? licensing? web-based editors?)
  • large corpus of existing material
MuseScore
  • large community
  • proven ability to represent advanced level notation
  • online/mobile freemium elements
  • essentially an editor-specific private data format
  • 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
  • copyleft online player/editor
  • formal specification
LilyPond
  • already integrated into MediaWiki, fits markup orientation, unicode
  • proven ability to represent advanced level notation
  • natively imports from, but does not natively export to, MusicXML (or any other format) (LilyPond->MusicXML export via several other GPL programs)
  • open-source visual editor and playback software (not web-based) exists, but see phab:T49528 (mobile might be harder)
ABC
  • already integrated into MediaWiki
  • ...
  • ...
  • ...
  • ...
MNX
  • should be perfect in every way :)
  • automatic conversion from MusicXML to MNX-Common should be possible
  • MNX-Generic provides a way to display and play any repertoire using SVG and audio files
  • does not yet exist, though MNX-Generic has a prototype web player
  • a full specification and an MNX-Common implementation
Braille music
  • usable by the blind, large digitized collections exist,[6] active community of users and transcribers
  • well-defined format[7]
  • format is somewhat culture-bound and may not be able to represent all musical traditions
  • copyleft visual/tactile non-markup editor exists[8] (the format resembles ASCII).
  • copyleft webpage display software exists (Braille or a colour- and text-coded visual isomorphism thereof).[9]
  • copyleft conversion tools exist from MusicXML and to MusicXML and LilyPond.[10][11]
  • Mediawiki integration

Discussion text

@HLHJ: There are good reasons for not supporting MuseScore as much as MusicXML, but I don't think these are enough to prevent users from merely uploading them. Upload-and-convert would sort of miss the point, since anyone who has the MuseScore application can already convert to MusicXML with the application. The main purpose of allowing MuseScore uploads at all would be to allow users to share files with MuseScore-specific notation that is erased when converting to MusicXML (e.g. pizzicato/harmon mute MIDI controls, some styling and positioning).

MuseScore 2 is much more mature than MuseScore 1 was at the time MuseScore 2 was released, so I doubt that there will be any further major compatibility issues. MuseScore 2 is also more than five years old now, so the vast majority of scores in existence wouldn't suffer from those issues. However, this is purely speculation, because we don't know how stable MuseScore 3 will be when it's released.

I don't think the difference in file size is enough to disqualify MuseScore files, given that orchestral scores with parts are usually more compact than average JPEGs (even the largest files probably wouldn't exceed a megabyte in any of the three formats).

I wouldn't worry about Commons cannibalizing the MuseScore online player or MuseScore Pro. MuseScore is free and open-source software, and there's nothing wrong with using it in MediaWiki. If Commons's infrastructure becomes able to compete with theirs (i.e. if it's good enough that someone starts a freely-editable MediaWiki wiki that accepts arbitrary non-free scores), then MuseScore Pro becomes an unsustainable way to earn revenue (and they do still have their mobile apps, and are now part of Ultimate Guitar as well). Do you know of any other file sharing service which limits users to five files? Jc86035's alternate account (talk) 09:28, 18 November 2018 (UTC) (edited 13:47, 24 November 2018 (UTC))

Regarding LilyPond, MuseScore does not natively export to LilyPond, and LilyPond does not natively export to either MuseScore or MusicXML. So, (a) any conversion requires going through MusicXML, and (b) there is no "official" way to convert from LilyPond back to MusicXML, as far as I know. Jc86035's alternate account (talk) 09:37, 18 November 2018 (UTC)

"MuseScore-specific" notation? Don't think there are any; MusicXML and LilyPond are much more open with what they do support, and I've already shown you that your listed examples are included. Further, MusicXML and LilyPond support more notations and customizations, and LilyPond has better output which may save the need for tweaking styles :)
Due to the unclear format specifications of the MuseScore format and the errors/"corruptions" found in MuseScore files (even in version 2), the maturity of the software is not at issue here. I have also stated the problems with the format before.
Don't really care about the file-size or cannibalization arguments. Please refute my claims (which I have substantiated) before repeating them elsewhere. Thanks! (Maintainer of the Score extension) Ebe123 (talk) 02:39, 19 November 2018 (UTC)
@Ebe123: I should have worded that differently (I've struck out "MuseScore-specific", since this is incorrect).
Presumably most MuseScore users, of which there are a not-insubstantial number, don't really care about the format being problematic, or at least tolerate it. At the very least, almost all .mscz scores made in MuseScore 2 shouldn't have any corruption issues when opening them in another instance of MuseScore 2, so it's not like every single MuseScore file uploaded to Commons would have corruption issues.
Regardless of the issues, if scores are being sourced from musescore.com (and there are a lot of scores with appropriate licensing there, although it would probably be necessary to cherry-pick uploaders without a track record of copying other people's scores) then keeping the original file on Commons would be beneficial (mainly for re-use and for PDF/SVG/OGG/MIDI export) if the Commons editor has modified the MuseScore file in any way. I would still prefer to allow MuseScore uploads, even if it's solely to compensate for MuseScore's limitations. Jc86035's alternate account (talk) 08:33, 19 November 2018 (UTC)
I don't think you understand my point about corruption. I am saying there are incompatibilities between the application and its own file format (in the same version), which leads to potential corruption. You're right that it "shouldn't" but it does (the frequency of occurrences is besides the point here but you're right that not all would) and you acquiesce to this. Furthermore, even if MuseScore users can "tolerate" this (do not believe that, but okay), the file format and its flaws must be taken into consideration if we are planning to support public upload and conversion of said files.
I do not understand the next paragraph. We do have bots like User:Flickr Upload Bot to source files from the web, but sourcing is outside the scope of this discussion. File versioning would be the same, again out of scope. "I would still prefer to allow MuseScore uploads, even if it's solely to compensate for MuseScore's limitations." doesn't make sense. Clarify? It seems to suggest creating a new MuseScore renderer. Ebe123 (talk) 18:00, 19 November 2018 (UTC)
@Ebe123: Sorry, I meant that it would be beneficial for users using the MuseScore app to convert files, not that Commons should be supporting automatic conversion to those formats. I'm not expecting anything more than uploads being allowed (for all three formats), particularly given that the wishlist proposal does not have anything near enough support to succeed.
Regarding sourcing, I meant that it would be a fairly obvious course of action to make use of at least some of the appropriately-licensed MuseScore files hosted at musescore.com (OpenScore scores: 1, 2). "Versioning" isn't really what I meant; what I was trying to get across was that if someone would want to re-upload or otherwise reuse a score in MuseScore format, it would be beneficial to them for the original file to be uploaded as a MuseScore file.
Not that I think the corruption issues are trivial, but file corruption is not unique to MuseScore or the MuseScore format, and corruption isn't a security risk in this case so (at least from the WMF's point of view) it shouldn't really affect whether or not uploads should be allowed. Furthermore, even if LilyPond is objectively better, it shouldn't prevent Commons from hosting MuseScore files; Commons still allows five different audio formats, and allows TIFF "as a courtesy" even though PNG is preferred. And MuseScore is, by every metric that I know of, more popular than LilyPond (almost twice by English Wikipedia page views, 25 times by Google searches, Alexa rank, questions asked on StackExchange…). In any event, file corruption was not enough to get me or anyone I know to switch from MuseScore to LilyPond/Frescobaldi/Denemo, although of course others may have had different experiences.
Incidentally, Wikimedia Belgium and/or its members have already had some sort of collaboration with MuseScore. Romaine proposed MuseScore ID (P4097) on Wikidata as part of this, although it's only used for ten OpenScore transcriptions so far.
@HLHJ and Abzeronow: In summary:
  • MuseScore is almost certainly more widely used than LilyPond by a significant margin;
  • All other scorewriters are either less popular than LilyPond or proprietary;
  • Because LilyPond doesn't have conversion to MusicXML, a large proportion of those uploading MusicXML files would have created the files with MuseScore anyway;
  • Commons is not limited to supporting only two more file types instead of three;
  • There is precedent (in MIDI) for allowing uploads for files that cannot be displayed on pages;
  • There is precedent (in TIFF and perhaps in MP3) for allowing uploads for common file formats even where better alternatives exist;
  • The file corruption issues do not occur especially frequently (especially not with newer scores), do not usually result in total data loss and shouldn't be problematic for security; and MuseScore is incomparable to LilyPond in this regard because LilyPond files are normally edited as source code (so corruption can only be caused directly by the user);
  • Only allowing MusicXML files to be displayed on pages and not MuseScore files may still be beneficial for re-users of the files because of import/export inconsistencies (regardless of whether or not MuseScore itself causes the problems);
  • Users may be deterred by only being able to upload files as .ly or .mxl, and people may find it easier to re-use Commons files which are uploaded twice as both .mscz and .mxl.
Jc86035's alternate account (talk) 08:29, 20 November 2018 (UTC)
(I would also note that MusicXML is not actually a Web standard yet – the status just means that some people formed a community group and put the specification on the W3C's website. It's not insignificant or a bad thing, but I think it's important to make the distinction to avoid making it seem like the other formats aren't legitimate.) Jc86035's alternate account (talk) 09:15, 20 November 2018 (UTC)
The MusicXML format specification is no longer maintained and the W3C Music Notation Community Group has switched to developing a new format called MNX (MNX is not yet ready for implementation). The reason this is happening is MusicXML was only ever intended as an interchange format for passing musical information between proprietary notation software. Its design makes it unsuitable for use as a native format, or for storing a working copy of a file, and attempting to use it as such results in loss of information compared to other formats. It is suitable for use when there is no other open format available (such as when exporting from a proprietary program), but should not be used for scores that were created in another open format, such as MuseScore or Lilypond. MuseScore is not without its flaws (what program is?) but it has improved greatly over the years. It's format is free and open source, and provides layout as well as semantic information, which is one of the main reasons why it is used by the OpenScore project (the other reasons being that MuseScore's desktop editor is free and open source, translated into over 40 languages, and is the most popular notation program according to Google Trends). Lilypond currently does not have a MusicXML exporter, so files created with Lilypond are not usable by other notation programs. (OpenScore Project Manager) --Peter Jonas (shoogle) (talk) 19:18, 20 November 2018 (UTC)
Thanks to Mirabilos for replying to me on m:Community Wishlist Survey 2019/Multimedia and Commons/Musical notation – files on Commons (rendering and playback), graphical editing. To keep the discussion together, I'll quote that 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.

I'm happy to take your word on files sizes, thank you for the info. Do you mean that an online editor might not be doable by the Community Tech Team, or that MuseScore/Ultimate Guitar wouldn't relicense theirs? There is clearly demand for a visual editor of music markup, with an aural player. People would want it to run on mobile, too. MuseScore's profit model is selling freemium use of their online and mobile software; their desktop software is fully open-source. If Wikimedia adoption of MuseScore made more people buy closed-source software from Musescore, that might be a problem for Wikimedia, especially if it meant lower-quality tool access for people with less money, as it would be a source of systemic bias. In the developing world, desktops are rarer, but mobiles are becoming more and more common (while bandwidth is expensive, hence my concern with size). If, on the other hand, the visual editor and player on Commons became favoured, and Commons competed with MuseScore's online and mobile products, MuseScore would no longer have a profit model. It could be a bit sticky either way. I'm not in any way condemning the MuseScore developers, who have written a great piece of free software that a lot of people clearly really appreciate. And if what I've seen of Peter Jonas (shoogle) is any guide, they are very nice people. His statement that "MuseScore would not view Wikimedia hosted files as a threat" is reassuring.
It looks to me as if the trade-offs run:
Format Advantages Disadvantages Technical difficulty Lacks
MusicXML *common interchange standard *being replaced by MNX *can be imported by ~any player, designed as an interchange format, not for display or editing *ongoing support
MuseScore *large community *online/mobile freemium elements *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 *copyleft online player/editor
LilyPond *already integrated into Mediawiki, fits markup orientation, unicode *does not export to MusicXML, only imports *open-source visual editor and playback software (not web-based) exists, but see phab:T49528 (mobile might be harder) *MusicXML or MNX export (NoteEdit, Rosegarden, Frescobaldi, all GPL, have code for this)
MNX *should be perfect in every way :) *does not yet exist *starting from scratch (can be an advantage) *a full specification and an implementation
MEI/Verovio *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

See updated collaborative table above. HLHJ (talk) 02:19, 28 November 2018 (UTC)

In other options, Verovio is LGPLv3-licensed, and is a lightweight engraver that creates SVG scores in the browser. It uses the en:Music Encoding Initiative's format. It also has a large community, but they are music scholars, interested in representing music from a wide range of periods and cultures. It is currently more editing/encoding than display-oriented. Verovio's display is designed more to be fast than print-quality elegant, but is quite functional.
It seems to me as if the easiest path on LilyPond might be to develop an MusicXML export function for Lilypond. This might not be too hard, as apparently NoteEdit (GPL) did it, and Rosegarden and Frescobaldi do it; import MusicXML and export Lilypond.[12][13][14] Developing a format conversion (accepting that you'd lose a lot of Lilypond's finer display points) seems easier than an entire WYSIWYG editor, subject to correction by those who know more than me; it seems the LilyPond community is not opposed (they even have some bounties on it). LilyPond also has some people very interested in MEI integration (LilyPond dev on relation between MusicXML and MEI), though they don't seem to have been active on it since ~2015.
On LilyPond being a dead end, I rather think that is its niche. It does not aspire to be a visual editor, but a markup and display format. It makes really nice, highly customizable music engraving. It is the music equivalent of a typography program. I believe it's also been used for sound and follow-the-beat highlighting.[15] For import/export abilities, see Comparison of scorewriters (which is incomplete). Apparently MuseScore used to export to LilyPond,[16] but no longer does.[17]
A LilyPond file is not literally a dead end; it can be imported and converted to MusicXML via other open-source programs (and thence to MuseScore). We could offer MusicXML download on Commons, directly and via auto-conversion from LilyPond. This would integrate the MuseScore community, which I agree is an important priority. Regardless of our choice of display and editing format, I think MusicXML is an obvious format to be able to import from and export to on Commons (at least until MNX is ready). Are the "pizzicato/harmon mute MIDI controls, some styling and positioning" you mention, Jc86035's alternate account, not exportable to MusicXML in principle, or does MuseScore not currently support it?
I see that MuseScore was/is heavily involved in MusicXML/MNX development;[18] more MEI-focussed groups, including LilyPond, are not. 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) 05:20, 23 November 2018 (UTC)

@Mirabilos: are you sure about Debian? I simulated it on an up-to-date Debian system, LilyPond was happy with a circa two-year-old Guile, but whinged that a font configuration library was too old. It has been four years since the last stable release, but this is a mature project and development is active (and apparently perfectionist). LilyPond looks as if it will have 2.20 stable for the next Debian release next summer-ish (according to one of the Debian package uploaders[19]), so everything earlier is probably moot here anyway :). HLHJ (talk) 06:13, 23 November 2018 (UTC)

@HLHJ: According to Ebe123 (on Meta) and Marc Sabatella (on the MuseScore forum), the instrument channel issue is fixable but would require development work in MuseScore (and I don't know how MusicXML works so I don't know if the import could retain it). I don't know if the styling issues are fixable but MuseScore 3's auto layout would act as a workaround for the export use case.
I agree that it would be appropriate to contact more people, given the nature of the RfC and that shoogle and mirabilos (both being contributors to the MuseScore source code) have already posted, although contacting the W3C community group via email and/or via their mailing list(s) would also help. Jc86035's alternate account (talk) 13:37, 24 November 2018 (UTC)
Also, given that Commons inherently doesn't accept non-free content, it probably wouldn't be possible for this website to cannibalize MuseScore anyway, even if the Commons software becomes better. Another website accepting non-free content with the same software would presumably be hindered by not initially having a massive pre-existing user base or any sort of publicity. (I've edited my comment above because I didn't realise that when I was writing it.) Jc86035's alternate account (talk) 13:47, 24 November 2018 (UTC)
Canvassing expert views
I've notified the MuseScore forum and the four mailing lists: W3C, MEI, lilypond-user, lilypond-devel. Jc86035 (talk) 10:28, 26 November 2018 (UTC)
No mailing list replies so far except one on mei-l, although one person has emailed me privately to say that they think MuseScore should be supported (presumably through score display/playback) over the other formats. I replied by asking them to post here because I myself have no power to make technical changes. Jc86035 (talk) 14:43, 26 November 2018 (UTC)
I have received another two private replies: one from the RNIB's music adviser, expressing support for .brf (Braille) scores; and the other from Mdgood, the creator of MusicXML, who has also commented below. (I have replied to both emails.) Jc86035 (talk) 11:00, 27 November 2018 (UTC)
I've also received an email about using ABC notation (.abc), which is already supported by the Score extension and would be presumably be as easily supported as LilyPond. I haven't added a survey section yet because the person who wrote the email said that they would post their own comments. Jc86035 (talk) 00:54, 30 November 2018 (UTC)

Member of the MEI Technical Team here. We would love to work with this community to get support for MEI into Wikimedia. I'd be happy to answer any questions about that. It's also worth noting that Verovio also supports MusicXML and **kern input[20] as well, so you get three formats for the price of one. :) Ahankins (talk) 10:49, 26 November 2018 (UTC)

Also (replying to self) it supports client-side MIDI playback, SVG, and PDF export. --Ahankins (talk) 11:38, 26 November 2018 (UTC)
@Ahankins: Hi, thanks for commenting. It would be nice if MEI would work with Commons/MediaWiki developers, although I'm not really a developer so I can't speak for them. I've corrected some of my earlier posts regarding MEI. (You might also want to add comments in the survey sections above.) Jc86035 (talk) 13:18, 26 November 2018 (UTC)
Also noting that I can't figure out how to send an email through to the LilyPond mailing lists. I have subscribed to both lilypond-devel and lilypond-user, but the server is not even sending back confirmation that I sent the emails (and I have confirmation emails turned on). Jc86035 (talk) 13:18, 26 November 2018 (UTC) For some reason all five of the emails to the two LilyPond lists were posted at the same time. Never mind. Jc86035 (talk) 14:37, 26 November 2018 (UTC)

I am a co-chair of the W3C Music Notation Community Group and editor of the MusicXML 3.1 Final Community Group Report. MusicXML is indeed maintained by the W3C Music Notation Community Group. The latest 3.1 update was released in December 2017. MNX is an exploratory project for a next-generation notation format that addresses use cases that have emerged since MusicXML's initial release. MNX does not make MusicXML either obsolete or unmaintained. Anyone may join the Community Group to participate in the development of the MusicXML, SMuFL, and MNX projects. Mdgood (talk) 22:21, 26 November 2018 (UTC)

@Mdgood: I will be editing the description to emphasize that MusicXML is not abandoned, although to me it seems that the statement "no longer maintained" would be correct (although somewhat misleading) if MusicXML 3.1 is to be the final version of MusicXML and MNX is to be a continuation of it. Jc86035 (talk) 11:08, 27 November 2018 (UTC)
MusicXML 3.1 is not intended to be the final version of MusicXML. There will be an update when the community decides that an update is needed. Mdgood (talk) 15:51, 27 November 2018 (UTC)

What is the objective of uploading music notation files to Commons? That isn't clear from this discussion. Is it to allow small excerpts of music notation to be included in Wikipedia articles as illustrations? Is the concept that those illustrations will have high-quality layout for their music notation, or merely adequate legible notation? Is the concept that the illustration could also playback the notated music? Or, is the concept that a full-length score for an entire piece be a free-standing document, which the reader sees as primarily a music score rather than as an illustration to something else? Most of the existing content will be full-length scores. Making an excerpt of a score to serve as an illustration will be an editing task with specialised tools, soft of like making a map or drawing a chart is. Many of the the discussion points here seem to waver back and forth between "illustration" and "full-length score". JimDeLaHunt (talk) 03:12, 27 November 2018 (UTC)

@JimDeLaHunt: In brief, Wikipedia articles currently use excerpts for most pieces longer than national anthems, whereas for Wikisource (and perhaps for Wikipedia) it would be beneficial to have the whole piece transcribed for both viewing and listening. In the currently available format (LilyPond) it would also be quite disruptive and against English Wikipedia guidelines to insert a full score into the middle of a page, whereas a thumbnail would be less so. There are some full scores (fewer than 2,000, most being from books of traditional songs) on Wikisource, of which the longest I've found is this transcription of Haydn's Surprise Symphony. Jc86035 (talk) 10:37, 27 November 2018 (UTC)

Adding a community summary table: I liked the table which @HLHJ: used to summarise their view of the pros and cons of adopting each format. It is a compelling and attention-grabbing format. However, I think the discussion has come up with a different consensus than what HLHJ's table expresses. I regard that table as HLHJ's own opinion, and I don't want to hijack it into a community-edited table. So, I inserted a table at the top of this section, explicitly to be community edited in an attempt to express a consensus from this discussion in concise, tabular form. Please edit and improve it. JimDeLaHunt (talk) 04:22, 27 November 2018 (UTC)

Thank you, JimDeLaHunt. You think better of my table than I; I wouldn't have called it anything so definite as my opinion, as I'm still trying to figure out all these formats. Thank you for the community version; I have collapsed my own, and will edit the collaborative one. HLHJ (talk) 02:19, 28 November 2018 (UTC)
I'm not sure where the point on 'SVG Animation' came from in the consensus table; there seems to be no mention of that in the text. It's worth noting that Verovio doesn't use SVG Animation (just SVG, which is supported by most, if not all, modern browsers). The MEI Community is also working on "MEI Basic" which is an 'official subsetting' of the MEI Spec, to address its complexity for the majority of use cases. --Ahankins (talk) 23:36, 27 November 2018 (UTC)

@HLHJ: Would it be appropriate to add .brf/Braille to the summary table? No one has brought it up yet, although I think it would be inappropriate not to consider it. Jc86035 (talk) 11:00, 27 November 2018 (UTC)

I'd very much favour this. I think that the RNIB's music adviser is referring to Braille music formats; will add, feel free to modify. HLHJ (talk) 02:19, 28 November 2018 (UTC)
I should have read that article more carefully. Modified from its last section:
So it seems we have a converter between MusicXML and Braille music already written, and a Visual (Tactile) Editor! I've written to inquire about the license of the latter. HLHJ (talk) 04:59, 28 November 2018 (UTC)
I am the developer of Braille Music Notator and Braille Music Viewer, and I'm flattered to hear that you might find them useful here. They are meant to be free and open, and in fact I have recently made both projects open source. I had always intended to license them under CC and realize now that I hadn't specified that on the site; if any of you can provide me with guidance regarding the license variation which works best for this type of usage on Wikimedia Commons, I will add appropriate license information to the project. (And thanks for the invitation to the discussion, @HLHJ: !) TobyRush (talk) 06:18, 28 November 2018 (UTC)
That's great! I hadn't spotted that GPL license, or the Github page, by some bizarre oversight. Thank you for the information. I don't think a Creative Commons license is needed for the software; CC is more designed for things like music score files. The GPLv3 is entirely suitable for software (the Mediawiki software is GPLv2 or later), so you don't need to add any licenses to make it compatible. This is looking as if it might be surprisingly easy to do. I'm delighted. HLHJ (talk) 01:49, 29 November 2018 (UTC)
No wonder you didn't spot the Github project; I created it within the last month or two and I don't think I've linked it to the original site yet anyway. Glad to hear the GPL license will work; please don't hesitate to let me know if there's anything I can do to make things work better with Wikimedia commons; I'm happy to do so. TobyRush (talk) 17:06, 29 November 2018 (UTC)

I think the MEI conversation is getting conflated with the use of Verovio, the renderer. While I wholeheartedly support the inclusion of MEI in Wikimedia commons, I can understand that its lower software support may be an issue. However, I think there is a very strong case for the inclusion of Verovio in Wikimedia as a score renderer, independent of whether MEI is accepted as a 'blessed' format:

  • It's open-source, liberally-licensed, actively developed, and constantly improving
  • It supports MEI, MusicXML, **kern, and Plaine and Easie. (The latter format is useful for rendering millions of incipits found in MARC files, since P&E is the only format approved for inclusion in MARC, and is used by the RISM project.[25])
  • It may not be up to the same engraving "beauty" standards as Lilypond or MuseScore, but it is by far the best client-side engraving library out there with broad open format support. This is a big win if you don't want to support complex server-side rendering setups.
  • It supports MIDI playback and client-side export to PDF
  • It supports Common Western (i.e., "Common Practice Period") notation, Mensural notation, and Neume notation (the latter two requiring MEI encodings, as there are no other supported formats for this type of music)
  • The SVG output supports CSS styling, and XPath queries into a data, meaning it can dynamically render portions of scores and highlight particular passages on-the-fly. This means that the same full encoding can be rendered in smaller snippets. (Use case: A full encoding of Wagner's "Ring Cycle" can be encoded, but individual Leitmotifs can be extracted from the encoding and described separately.

(Full disclosure: I am part of the Verovio project) --Ahankins (talk) 10:56, 28 November 2018 (UTC)

That's probably my fault, I put them in one table row and survey question. I'll try to clarify, and thank you for the alert. The extractability functionality sounds really useful for this application, as files no-one can modify are really not Commons's thing. Commons is used on a broad variety of hardware (increasingly, mobiles), and over connections which vary over the full range of speeds and costs. It also gets downloaded and mirrored, making file size important.
MARC standards are used in library catalogs, according to the Wikipedia article. The RISM music catalogue looks great, and it's CC-BY![26] I found Kernscores, which seems to use yet another format, the ASCII-based **kern you mentioned and its relatives.[27]
I think I should explicitly say that this is not a decision about what formats will be approved in some way, nor will the most favoured format(s) be instantly implemented. Obviously including MNX is a nonstarter until it exists, but we are still discussing its possibilities. This being a sort of informal democracy, we are trying to decide where effort would be best spent; any and all decisions are subject to revision at any time.
Last but not least, welcome to all the new and returning editors here. Having such varied expertise contributing to this discussion is very useful. I also really appreciate the spontaneous conflict-of-interest statements, it's great to see such sympathy with community norms. HLHJ (talk) 01:49, 29 November 2018 (UTC)
Sorry, I should have noted that MARC is a library standard! Kernscores is part of the work happening at Stanford University, where they've been collecting encoded music since the 1990s in various formats. Craig Sapp (at Stanford) has been the lead for developing **kern support in Verovio, and he maintains Kernscores as well as works on projects like the Josquin research project, The Chopin Institute, the New (new) Complete Mozart edition, etc. He's done some pretty cool stuff with his Verovio Humdrum viewer (http://verovio.humdrum.org/ -- click 'play' and it's pretty cool), and automatic conversion between encoding formats (Kern <-> MEI <-> MusicXML <-> MIDI). — Preceding unsigned comment added by Ahankins (talk • contribs) 10:29, 30 November 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2018/11&oldid=333952007"