Aug 2 2020
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.
Jul 31 2020
@Petrb: Thank you! I understand plans being a bit disrupted this year, tho.
Feb 2 2020
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)
Jan 21 2019
See https://en.wikipedia.org/wiki/Template:Graph:Highlighted_world_map_by_country for a simplified but useful case.
Jan 20 2019
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.
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.