Wikipedia:Wikipedia Signpost/2013-04-22/Technology report

Technology report

A flurry of deployments

Wikidata phase 2 deployed to English Wikipedia

On Monday, the English Wikipedia became the 12th wiki to be able to pull data from the central Wikidata.org repository, with other wikis scheduled to receive the update on Wednesday. The deployment gives users access to a {{#property:}} parser function, most obviously suitable for use in infoboxes.

Wikis are not obliged to use the new functionality they will receive. As the Signpost reported two weeks ago, the English Wikipedia community remains divided on the matter, although the early indications of an RFC established since are that the phase 2 code will be put to at least some use there, if only on a trial basis.

In related news, the English Wikipedia will have version 5 of the Article Feedback Tool re-enabled this week on an opt-in basis, following its rejection of the function for general deployment last month. In addition, wikis including the English Wikipedia have, eight years after bug #189 was opened requesting the feature, finally gained access to a new <score> pseudo-HTML tag, analogous to <math>, but providing instead for the creation of music notation on the fly:

$\relative c' { f d f a d f e d cis a cis e aes g f, e f d f a d f e d }$

English-language Wikipedia to be first to receive Echo deployment

Facebook users will feel at home with the choice of user interface for a new notifications system, Echo, which will be deployed on its first Wikipedia within the next week.

Within the next week, the English Wikipedia will become the first Wikipedia to benefit from Echo, a major WMF-developed extension aimed at providing MediaWiki with a Facebook-style notification system. Though many types of notifications are possible, this initial deployment will focus on providing only core updates, including news of new user talk messages. More controversially, these kinds of notifications will launch in an "opt-out" fashion; users opposed to the change will be directed to a user preference toggle.

Announced nine months ago, the Echo project has lived a comparatively quiet existence, with trial deployments on MediaWiki.org rarely causing a stir. Proponents point to the applicability of Echo to both power-users (who may be monitoring many different goings on) and first-time editors (who find Wikimedia wikis' idiosyncratic array of news channels confusing), while detractors cite the potential for users to be overwhelmed with a torrent of notifications of varying importance.

The extension will supersede the existing email notification system, opening the door for new types of email notification to be added. However, as developers behind the project were keen to point out, the email half of the system will be strictly opt-in: no existing user should begin receiving email notifications for which they did not previously sign up.

In brief

Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks.

VisualEditor opt-in test expanded: This week, 13 Wikipedias join English Wikipedia in the opt-in alpha test of VisualEditor. Nine of the new test sites rank 2nd to 14th (behind English Wikipedia) in size; the other four were selected as challenging environments (including Hebrew and Arabic). For those participating in the test, VisualEditor is now the default editor when a tester clicks the "Edit" tab; clicking an "Edit source" tab starts the current editor (wikitech-l mailing list; see also previous Signpost coverage for background). When testing is satisfactorily completed, VisualEditor will become the default editor for all users unless they opt-out. Developers plan full deployment in late July.
WMF Director of Technical Operations to step down: CT Woo will be standing down from his position in approximately three months time, he reported this week (also wikitech-l). Woo, who gave an interview to the Signpost in July, cited "the growing and maturing of the TechOps department, resulting in significant improvement in both the technical infrastructure and service processes" as the greatest achievement of his two-and-a-half years on the job. Certainly, the period has seen the WMF operations team largely succeed in keeping performance in line with a boom in visitor numbers, even if outages have stubbornly popped up in this report. It was also announced that "web developer and operational jack-of-all-trades" Erik Bernhardson will be joining the Foundation as a features engineer.
Toolserver users to get year to migrate: Toolserver developers will get a year to migrate to Wikimedia Labs under a draft timetable published by service provider Wikimedia Germany. Although developers can already start moving their tools over, the Labs project is not expected to have all of the desired functionality until the end of June 2013. Tool owners will then have until the end of June 2014 to complete the migration process, about six months longer than under the original timetable, published last September. In turn, Wikimedia Germany promises to support all those needing help with the potentially difficult transfer, though as WMDE toolserver manager Silke Meyer admitted this week, "it is not clear which tools will not be able to move ... or which maintainers might decide not to move and why".
Wikipedia adopts MariaDB: As reported on the Wikimedia blog this week, the Foundation has now completed its transition from using a Facebook-developed fork of database management system MySQL to community-developed fork MariaDB. The change brought considerable performance improvements of about 20%, WMF performance engineer Asher Feldman reported; however, users are unlikely to notice the change, since database reads constitutes only a small proportion of total request time when viewed from the user's perspective. As reported in the Signpost last December, the move also visibly lends the Foundation's support to the MariaDB open-source project following its split from the main MySQL project in 2009 amid licensing concerns.

← Previous "Technology report"

Next "Technology report" →

In this issue

22 April 2013 (all comments)

In the media

WikiProject report

News and notes

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

Echo

"Proponents" and "detractors" carries no citation or evidence. Could they be provided? :). Okeyes (WMF) (talk) 23:17, 24 April 2013 (UTC)[reply]

As you could probably tell from the lack of quotation, both are agglomerations from multiple sources. For example, the proponents suggestion mirrors some of the MediaWiki page and slides; the detractors section mirrors some of the many discussions on VPT about notification systems in general (though admittedly the application to Echo may be novel; it's hard to tell when you've been reading critical -- not necessarily negative -- commentary about a project for months and months like this). If you had a more specific concern, I could perhaps find a specific reference regarding that point. - Jarry1250 ^{[Vacation needed]} 22:36, 28 April 2013 (UTC)[reply]

I'm confused. You're telling me that the detractors section is based on discussions on the village pump about the general concept of a notifications system, and therefore applies to a specific implementation? The idea that it would lead to a torrent of notifications is a potentially valid one - we had a bug on MediaWiki.org, for example, that caused that temporarily - but things like that are precisely the sort of statement that need to be specific, not general. "Notifications will make us like Facebook" is a general, conceptual concern that can plausibly (although wrongly) be applied to any implementation, including Echo. "Notifications will include tons of notifications that overwhelm everything" is something entirely dependent on the implementation. Citing generalised discussions really isn't useful in this case. Okeyes (WMF) (talk) 03:01, 29 April 2013 (UTC)[reply]

"rarely causing a stir" I remember a little bit of a stir when in the early stages there was a bug massively spamming users on mediawiki.org (Long since fixed). Bawolff (talk) 15:56, 25 April 2013 (UTC)[reply]

The score tag

Eight years seems a bit long to get it implemented.--Rockfang (talk) 14:47, 25 April 2013 (UTC)[reply]

Well the current work that resulted in the recent deployment, was really only started in December 2011 when Graf Zahl rewrote the lillypond extension as score. (Which arguably is still a really long time) Bawolff (talk) 15:54, 25 April 2013 (UTC)[reply]

I'm presuming it produces only single-line melodies. Is this correct? Tony (talk) 09:21, 26 April 2013 (UTC)[reply]

We are still playing on Wikisource where it will allows us to get back to do more work on sheet music. Here is an example of some more complex coding s:Page:A Dictionary of Music and Musicians vol 1.djvu/24. — billinghurst sDrewth 12:58, 26 April 2013 (UTC)[reply]

Thanks, billinghurst. The tenuto symbols should normally be on the notehead rather than the stem sides, I think. It's a very complex task; the simple outputs I see thus far are pretty good. Notating melodies is useful, but it won't be until more than one part can be displayed that we'll start to see the potential for many western-music articles. Even non-western music traditions often need multistave systems for the (approximate) notation of samples of ensemble music. Tony (talk) 13:59, 26 April 2013 (UTC)[reply]

Normally, the tenuto marks would be on the notehead side, but if you look at the original source on the page billinghurst posted, you'll see that the marks are indeed all above the staff as rendered. That makes the <score> rendering faithful to the original, which is what we should be aiming for. Powers ^T 16:13, 26 April 2013 (UTC)[reply]

I'd regularise rather than regenerating non-standard and problematic notation. For example, being faithful to an original doesn't involve reproducing the exact spacing between the notes—just as certain changes are permitted to quoted linguistic text by the Manual of Style. As long as the original meaning is reproduced faithfully, ease of reading is a desirable goal. Tony (talk) 10:31, 27 April 2013 (UTC)[reply]

Well that'd be a question for Wikisource's style mavens. Powers ^T 13:28, 27 April 2013 (UTC)[reply]

Lilypond

An example with chords and sound-file generation.

{
<c e g b>
<d f a c'>
<e g b d'>
<f a c' e'>
<g b d' f'>
<a c' e' g'>
<b d' f' a'>
<c' e' g' b'>
}

Lilypond is great! Kiefer.Wolfowitz 15:37, 26 April 2013 (UTC)[reply]

How do you get it to play? I press the button and nothing happens. Tony (talk) 03:14, 29 April 2013 (UTC)�[reply]

I use Firefox running on Ubuntu's GNU Linux, and I just hit the button; Wikipedia is trusted by my computer, though. With Windows, you might left-click open in a new window (and perhaps reload). Kiefer.Wolfowitz 06:44, 29 April 2013 (UTC)[reply]

Works fine with Opera 12.15 on winxp. -Yyy (talk) 12:52, 30 April 2013 (UTC)[reply]

Works fine with Firefox 20.0 on a Mac running 10.8.3 (Lion). -- John Broughton (♫♫) 03:24, 2 May 2013 (UTC)[reply]

Room for improvement

It is possible to get SVG output from Lilypond which can be animated on playback. See Animated SVG Percussion Music. Here's a nice tech post about it: [1]. See it live on http://percussion360.com/. Click the tiny "play" button. Maybe he'll open source this if we ask nicely. The thread posts are all over the place, I use Google like this to find them. I think ly2video is inferior since everything can be generated client-side, which scales better. Tell me what you think. --Ysangkok (talk) 12:56, 1 May 2013 (UTC)[reply]

This question is better addressed to the Lilypond project, which does not yet support exporting svg files from within Lilypond, I believe. The manual suggests command line directives. (It would be better for WMF to focus on e.g. guitarists' wishes for alternative tunings and fretboard diagrams). Kiefer.Wolfowitz 13:40, 1 May 2013 (UTC)[reply]

Exporting SVG is indeed supported, see the tech post. The problem is to make the connection between SVG shapes and notes. His solution is kind of hacky. Marrying MusicXML and SVG would be beautiful. --Ysangkok (talk) 14:35, 1 May 2013 (UTC)[reply]

Please notice the keywords: " from within Lilypond.... The manual suggests [terminal] command-line directives". Kiefer.Wolfowitz 15:11, 1 May 2013 (UTC)[reply]

What manual? The lilypond one? It has the SVG documented on this page. Command-line directives are passed to the lilypond binary, it does the SVG itself. --Ysangkok (talk) 17:12, 3 May 2013 (UTC)[reply]

VisualEditor

The version of the VisualEditor report I edited said VisualEditor is in beta testing. The VisualEditor itself says that it is in alpha test, which is correct based on my experince with it (I mean that as a factual statement, not a criticism).—Finell 18:36, 25 April 2013 (UTC)[reply]

I have yet to successfully make an edit with the Visual Editor. Powers ^T 16:18, 26 April 2013 (UTC)[reply]

Most of my VisualEditor edits worked correctly. A few had weird results, such as text that disappeared. I would do more editing with VisualEditor if it were the default editor when editing just a section.—Finell 21:44, 28 April 2013 (UTC)[reply]

Perf improvements

Could you explain the perf improvements in MariaDB, since they are not noticeable by users? What performance metrics were improved, if not for the users? (I'm not a techie, which is why I ask). 74.202.39.3 (talk) 02:11, 26 April 2013 (UTC)[reply]

To quote the blog post "For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds." Im not an ops person, so the following is a total guess and may be totally wrong, but I would guess that db latency isnt exactly a bottleneck, so efficiency improvements are probably more long term scalability benefits rather than immediate make the site faster benefits (although they probably do make the site a bit faster). Bawolff (talk) 22:14, 27 April 2013 (UTC)[reply]

My interpretation is the same as Bawolff's, and it's what I consequently hinted at in the report: users are unlikely to notice much of a difference, but hey, every little helps (as we say here in the UK). - Jarry1250 ^{[Vacation needed]} 22:36, 28 April 2013 (UTC)[reply]

Make sure we cover what matters to you – leave a suggestion.

Home

About