Sticking to the schedule detailed inlast week's "Technology report", 1.18 has so far been released to seven Wikimedia wikis for testing and evaluation. Developer Rob Lanphier has since writtenon the wikitech-l mailing list that the partial deployment (the first such deployment in Wikimedia's history) "mostly went well", with only the LiquidThreads extension and a series of compatibility fixes with the ResourceLoader needing to be adjusted at the eleventh hour. The deployment means that those seven wikis now have access to a range of newer features, with meta.wikimedia.org, en.wikiquote.org, en.wikibooks.org, beta.wikiversity.org, eo.wikipedia.org, nl.wikipedia.org and incubator.wikimedia.org following today. The preparatory work for today's updates has been causing intermittent server overloads, resulting in edits not being processed. Nonetheless, the problems are expected to be temporary, and all remaining wikis remain set to be changed over by 4 October.
In addition to those features outlined in last week's report, Brion Vibber chose this week to highlight the resolution of bug #6672, allowing for the native support of photoswhere EXIF metadata specifies a non-default orientation. Vibber explained the pre-1.18 problem (1,2):
| “ | This is very common in photos taken with digital cameras; a portrait-mode image may be saved [as landscape] with an orientationtag stating it must be rotated 90 or 270 degrees ... While most photo-editing applications understand this metadata natively and will simply show the image at its natural size, web browsers don't -- and neither did the server-side processing that MediaWiki was doing. When this support goes live on Wikimedia Commons, it'll be a nice help for people uploading [photographs directly from their camera], as it will no longer be necessary to manually fix the rotation of your photos. | ” |
WMF localisation team member Gerard Meijssen passed on a reminder to administratorsreading his blog (originally written by Right-to-Left expert Amir Aharoni) to check for broken Right-to-Left-related JavaScript and CSS on their home wikis after the deployment of 1.18, which makes a number of these so-called "hacks" superfluous.
MediaWiki code is collaborated on using a system known asSubversion (seepreviousSignpost coverage for details), which, for a long time, was the standard in collaborative code development. In recent years, however, several alternatives have become popular, each offering a diverse array of possible improvements over traditional Subversion. Most significantly, the rise ofdistributed revision control systems offers developers a chance to abandon the linearity of Subversion commits in favour of dynamic "changesets", which can be applied in a different order from predecessor changes, or simply not at all. This ability derives from the fact that under a distributed system there is no central repository, and so no canonical order of changes in the first place, allowing developers the freedom to code without the prospect of a time-consuming merge at the end of the process (the developer equivalent of a complex edit conflict). As a result, a move away from Subversion (which is increasingly seen as outdated) to a distributed system such asGit has been suggested a number of times in the past, including inMarch of this year.
On 22 September, developer Rob Lanphier re-opened the case on thewikitech-l mailing list, if only to declare victory for those in support of a move. "For a long time, we've been talking about migrating from Subversion to Git," wrote Lanphier. "It's time to start getting more serious about it. ... There has been resistance to this in the past, and there still may be some resistance. However, I think we've worn everyone down. :)". Historically, criticism of any move has focussed on the practicalities, rather than direct criticism of Git itself, which has over time acquired something of the "mythical" about it, in the words of bugmeister Mark Hershberger, writing earlier this year. On this basis, Lanphier concluded that "the questions shift from "if?" to "when?" and 'how?'" and proposeda timetable that would see Git replace Subversion in November. With linearity abandoned, the long-talked-about goal of continuous integration (for example, weekly deployments of the newest code to Wikimedia wikis) has been brought forward accordingly and would, if the migration went according to plan, begin during December.
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.
.png)
{{#babel:}} parser function. It replaces a complex system of templates, currently in use on most major wikis.