Would it be helpful if it just linked to the section (basically same as the [edit] links)?

Thank you for the explaination. So it'd need an entirely seperate server to relay the mail, and proxy the IPs, and it would be unreliable and probably not worthwhile?

You're quite right, for most cases. But the people who really need to keep their identities private may well be living in countries where free e-mail providers like Gmail are blocked, and registering a domain is not the easiest task to do anonymously. These approaches have their own attack surface. Private, individual countermeasures to control e-mail leaks are also more complex for the user to implement.

Having two levels of Checkuser right, one for users who have created accounts and a lower-level one for those who haven't, seems sensible. This would be pretty similar to having cloaks.

That's great, if these exposures only apply to developer accounts, not the default accounts, they are much better notified. Apologies for my confusion, and thank you all for clarifying.

Thank you, bd808. That's much clearer.

Okay, done at T320585. Thanks!

What is the status of stuff related to the confusing 2012 draft of a user agreement to disclosure of IPs and passwords, which seems to be partly contradicted by its talk page and maybe be part of the terms and conditions for some projects (Cloud services? Toolforge?) ? It is mentioned above, and un-checked-off, in OP>Content checklist>Links.

I'm not in the least questioning your judgement. Thank you for all the work you've put into this, and apologies if I've asked questions that can't be publicly answered. If Lilypond has seriously intractable security problems, would the LGPL Verovio be useful? It renders SVG scores from MEI, MusicXML/~MNX, **kern, and Plaine and Easie. MEI is an academic format that strives to be cross-cultural, so should handle archaic notation.

A minor lyrical winkle. If we could store scores on Commons, we could transclude them into other wikis as we do images, and avoid repeatedly re-transcribing them. But lyrics would be best stored and transcluded seperately, because it's common for one score to have multiple sets of lyrics.

A way to turn off live preview, say by a radio button next to the word "Preview", should probably also allow discrete previews on request, maybe by clicking on the word "Preview" itself, as with the current button for markdown editing.

It seems as though the main problem may be that if you have any text in the reply tool, it will never drop it, even if you reload the page. It really wants to recover your unsaved changes.

Thanks, Matamrex! I can confirm that if I disable the "Show preview without reloading the page" setting at https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-editing-discussion, the recursive step of the bug does not appear. You still get both editors open simultaneously, tho (the part I described as "oddly" in the OP). I'm fairly sure that setting is enabled by default.

So does this need to be moved back to "Backlog"? Wikisource has a fair number of transcriptions hanging on this resolution, including some which were already finished and proofread before the "Score" problems were noticed and now won't display. What needs to be disabled for security?

This issue was mentioned in connection with the new reply tool.

Two related issues:

This is closely related and so I'll add it as a comment here. If the filename is overlong, the image file has already been uploaded, or there are forbidden characters in the filename (including invisible whitespace characters), the upload fails with the same error message ("Error Upload failed"). It can be slow guessing what is wrong.

If inline tags are being applied to specific edit (as is usually the case) in a computer interface that can easily identify the edit (as here), there is an additional opportunity.

@Petrb: Thank you! I understand plans being a bit disrupted this year, tho.

Goals of the feature

• make inline tagging faster and easier by semi-automating it
• make inline tagging more common, as it was pre-2007, when editor retention rates were higher and vandalism rates lower (semi-automated tools were developed to respond to rising vandalism)
• improve newcomer editing skills more quickly, so that newcomers can fix their own early edits, reducing the burden on experienced editors
• give desirable new editors prompt, constructive criticism (there is evidence this improves editor recruitment)
• improve the retention of flawed but fixable edits by new editors (there is evidence this improves editor recruitment)
• reverse the post-2007 slow decline in the number of active editors, and return to exponential growth in the number of active editors

• Discussion at the Community Wishlist: Dealing with unsourced additions - "citation needed" button (one oppose, one neutral, ~40 support; Huggle and Twinkle communities were canvassed on their talk pages)

See https://en.wikipedia.org/wiki/Template:Graph:Highlighted_world_map_by_country for a simplified but useful case.

T49528, "Create a VisualEditor plugin tool to add/edit musical scores", was also discussed in the RfC, and should probably be referenced here.

Apologies for the multi-part task, and thank you for the link to https://www.mediawiki.org/wiki/Phabricator/Help. Could a question-mark icon or some such next to the e-mail field link to that help page?

Thank you for the very clear question, Aklapper, it makes my bug report look rather shoddy by contrast. Indeed, your numbered list is exactly what I did. After giving my unified login credentials and pressing "Allow", I got the message

You are entirely correct, @Jc86035. I had somehow misremembered it as MIT-licensed. The online and mobile versions are proprietary, but the desktop version is GPLv2. Apologies for the mistake, struck.

I was presuming that those who are sighted would prefer to use the other formats. I've never used Braille music, so I'm probably wrong here. I think if the dev is willing to implement it then that's great.

I take it that by "thumbnail", we mean visual display, and "playback" aural display.

Gently disagreeing with @Jc86035 on screen rendering. The Braille format also has a visual web display, the thing I called a "colour-coded sighted isomorphism" of Braille. It is really useful if one is sighted and used to reading text and colours (we might want to check if said colours are colourblind-safe). It would be very helpful to transcribers to have this visual interface.

As another option, LGPL Verovio also does playback of MusicXML (used by everyone) , MEI (a format used extensively by academics for PD works), Plaine & Easie (librarians), ABC, and **kern (still figuring that one out). However, it is Javascript-heavy.

MusicXML had the broadest support at the RfC on music formats.

I agree that MEI could be useful without Verovio, and Verovio without MEI. Would it be good to split out Verovio into another task?

Would one be able to transclude them into articles? It might be a bit more compact than, say, this.

I'd agree that an extension based on MuseScore software seems problematic, for the reasons above and for reasons discussed in the RfC. To summarize, MuseScore software is partly open-source, but not copyleft, and may therefore be made closed-source at any time. The community centers around a single commercial website with licensed non-free content as a major draw, and the website/company/software has already undergone one takeover. The desktop version is open, but the online/mobile version is proprietary, raising issues of systemic bias given the large number of people worldwide with no desktop. For these reasons, and the low support in the RfC, I would suggest that this format be a lower priority.

See this table of GPL software that does this conversion.