An example of an RTL interface (the Arabic Wikipedia's mainpage): a complete mirror image of that of the English Wikipedia
This week, bugmeister Mark Hershberger issued a call for more developers routinely using right-to-left (RTL) interfaces to get involved in MediaWiki ("Entries in Life" blog). The main MediaWiki interface in languages which are written right-to-left is virtually a complete mirror-image of that for all other languages (in contrast to the English Wikipedia, the sidebar is on the right, for example, and Vector's search box on the left). This can cause problems when changes are developed and tested solely on left-to-right (LTR) wikis, as is often the case at the moment.
Despite [internationalisation] support, MediaWiki and Wikipedia lack in some pretty important areas. One of the areas that this is most obvious is in languages that are written right-to-left (RTL) instead of left-to-right (LTR). We do try to fix these problems, but almost all of our developers work in LTR languages, so we don't notice the problems as quickly. The problems don't stare us in the face every day and wiki users in RTL languages like العربية (Arabic), فارسی (Farsi), and עברית (Hebrew) don't have proper support.
He added, "if you're an RTL developer, let me tell you clearly: We want you!".
Account Creation Improvement Project update
On 27 April, the Wikimedia Techblog carried an update from developer Nimish Gautam about the progress of the Account Creation Improvement Project (ACIP). In particularly, the update included details on some of the technological developments that had accompanied their attempts to buck the (largely) downwards trend in the number of users registering and editing on the English Wikipedia over the past couple of months.
Among these, Gautam noted the deployment of the CustomUserSignup extension on 27 April. The extension allows the destination of the "Log in/create account" link to be varied between visitors, allowing the ACIP team to customise "the look and messaging of these screens to see what kind of impact that has on new editors" more easily than before, when the page had to be changed for all users for two days at a time. In addition to the raw statistics on how many potential editors successfully make it through the registration process, the project is also collecting data on users' activity levels after registering via a tracking cookie associated with a browser session rather than with an individual user or user account. Information collected includes:
Which account creation messaging group the user was placed in (identified as ACP1, ACP2 or ACP3 for now)
What version of the account creation campaign they received
Whether the particular user made it to the end of the account creation process, or whether they dropped off after reaching the login screen or the account creation screen
If (and only if) the user creates a new account, the number of edits or previews during the course of the trial.
In addition, the project has also utilised an improvement to the ClickTracking MediaWiki extension, which helps to collect anonymous information on users editing habits, to allow multiple tests to be run in parallel, rather than sequentially. As of time of writing, ACP1, ACP2 and ACP3 are identical, but this will be changed shortly.
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks. Those interested in the release of MediaWiki 1.17 to external sites should take note of this thread, which suggests a beta release is imminent.
Developer Brion Vibber blogged about a recent bugfix (involving the patch for bug #26729 going live) that he described as showing that "we’ve got a basically sane setup where issues can be pushed along from confirmation to merging to testing to deployment in a reasonably speedy fashion". In a separate post, he also detailed his plans for adding support for the OEmbed standard to MediaWiki, mainly to improve the ease with which videos hosted on Wikimedia sites can be reused. The standard would need to be expanded slightly to include licence metadata before it met Wikimedia needs, however.
With the resolution of bug #18682, alternative ("alt") text can now be set for images in image galleries.
Gerard Meijssen blogged about the limited range of fonts currently supported by MediaWiki's SVG rendering software.
Sweble Wikitext Parser, the latest in a line of 30 or more attempts to reimplement the MediaWiki parser, has been released, with some remaining bugs. Brion Vibber, the developer now responsible for in-house improvement of the parser, noted that Sweble "should be a good help as we migrate towards a unified canonical parser model" (identi.ca). Such a migration, given the millions of lines of existing wikitext the HTML equivalent of which would need to be accurately reproduced, has long been seen as a Herculean task (see, for example, last year's April Fool's announcement of it finally being achieved).
The Toolserver's copies of the JIRA (an alternative to Bugzilla) and FishEye software were successfully upgraded and the latest pre-release version of Perl (5.14.0-RC1) is available to Toolserver developers to use (toolserver-l mailing list).
Mark Hershberger also blogged about a new page he has written for developers about how best to go about getting their custom extensions deployed to Wikimedia sites.
After a false start, the EmailCapture has been enabled, allowing the email addresses of unregistered users to be provided, validated and then used to send out mailing to potential editors. It has been developed for use, at least initially, with the ArticleFeedback extension (server admin log).