The Wikimedia Foundation's Engineering Report for October was published last week on the Wikimedia Techblog and on the MediaWiki wiki, giving an overview of all Foundation-sponsored technical operations in that month. Many of the projects mentioned have been covered in The Signpost, including the New Orleans hackathon, the introduction of native https support for all Wikimedia wikis, and the local deployment of MediaWiki 1.18. Also included among the headlines on the report were the deployment of the Translate extension to Meta-Wiki and the completion of the first revision of the MediaWiki architecture document.
As described in brief in last week's "Technology report", progress is being made on a new parser and visual editor combination. The official engineering report documented exactly where that progress was coming from, with at least six developers (Trevor Parscal, Inez Korczynski, Roan Kattouw, Neil Kandalgaonkar, Brion Vibber and Gabriel Wicke, who only joined the team recently) each working on different elements of it concurrently.
Progress in other areas was more restrained but still being made; for example, developer Andrew Garrett worked on a script to convert existing LiquidThreads installations to the new, revised schema. Likewise, the "last critical bugs" in version 0.9 of WMF-supported offline reader Kiwix were fixed, with the release candidate cycle expected to begin shortly. There was also some bad news in the report, however, as it described how data analyst Erik Zachte had discovered inconsistencies in his report card numbers, which were investigated and attributed to packet loss of up to 25%, rendering several figures unreliable.
Scheduled for November are substantive work on the Git conversion and https support on the mobile platform to mirror that available on the non-mobile site.
With the switchover to native https slowly fading into history, the baton for ensuring total security has been passed on to script writers. This is because, although all interface images were switched over to using protocol-relative URLs, many user scripts will also have to be updated to use the new format.
Forcing use of insecure images or dependency scripts negates much of the benefit of using a secure site; as a consequence, browsers are right to show warnings, Ryan Lane explained. And as Brion Vibber described, the warnings are often very obvious: "Firefox can throw up a scary dialog box on every page view... Chrome does the big scary X-ing out of the 'https'... IE in latest versions just ignores any of the content that came over HTTP unless you opt back into it by clicking on a little bar at the bottom of the window" (Words and what not blog).
And so, with increasing numbers of users expected to switch to using the https version of the site, more and more script developers have been working to clear up any warnings; nonetheless, help will be needed within smaller sites to fix code copied and pasted from larger wikis months or even years before the https support went native.
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.
As developer Chad Horohoe explained on the wikitech-l mailing list, the conversion from SVN to Git requires that names and email addresses be input for all contributors to the project. Since SVN had no such requirement, help is needed to pair up the correct names and email addresses with old developer pseudonyms (help now).
Discuss this story
An email petitioner asked if we could change Signpost links to https; I wasn't sure if this would mess things up for people being logged-out etc. Would it be possible to accommodate both constituencies? Skomorokh 18:32, 11 November 2011 (UTC)[reply]