Wikipedia:Wikipedia Signpost/2011-05-09/Technology report: Difference between revisions
m Fix author bylines (via WP:JWB) |
m Protected "Wikipedia:Wikipedia Signpost/2011-05-09/Technology report": old newspaper articles don't need to be continually updated, the only real edits expected here are from bots/scripts, and vandalism is extremely hard to monitor ([Edit=Require autoconfirmed or confirmed access] (indefinite) [Move=Require autoconfirmed or confirmed access] (indefinite)) |
(No difference)
| |
Latest revision as of 01:32, 6 January 2024
MediaWiki 1.16.5, 1.17b1; 1.18 branched; UploadWizard the default; Berlin Hackathon; brief news
MediaWiki releases: 1.16.5, 1.17b1 and a branch for 1.18
This week saw a number of developments regarding the MediaWiki software on which Wikimedia Foundation wikis run. The first, on the 4 May, was the announcement of a security update to MediaWiki 1.16, the version currently considered stable enough for all major external wikis to use (wikitech-l mailing list). Version 1.16.5 closed another security loophole related to those closed in 1.16.3 and 1.16.4 (see previous Signpost coverage) and additionally fixed a flaw in MediaWiki's implementation of $wgBlockDisablesLogin that allowed users to mimic unblocked users' cookies in order to gain additional permissions (no Wikimedia wikis were affected).
| “ | Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. | ” |
| — Developer Tim Starling on 1.17b1 (wikitech-l) | ||
Two substantive announcements were also made on 5 May. The first, of interest almost exclusively to users operating their own external wikis, was the release of a beta version of MediaWiki 1.17, the version already running on WMF sites (wikitech-l). The second, perhaps of more interest to Wikimedians, was the branching of MediaWiki version 1.18 (also wikitech-l). Although some changes are deployed out of process to Wikimedia sites, new releases such as 1.18 contain many smaller improvements of interest to editors and visitors alike. With 1.17 already live, branching 1.18 represents a significant step towards the deployment of another batch of improvements, already slated to include 179 bug fixes and feature requests, plus localisation updates (provisional release notes). 1.18 will now be left to "bake": no new features will be added to it as the release is purged of bugs, before going live to Wikimedia wikis ahead of a release to external sites. Commenting on the branch, former CTO Brion Vibber's post to wikitech-l consisted solely of the word "Woohooooooo!"; meanwhile, however, debates will no doubt be ongoing about the future shape of the MediaWiki release schedule.
UploadWizard to become default
After a period of being one option among many for uploading files to Wikimedia Commons, the new UploadWizard is to become the default on or around 9 May, it was announced this week (Wikimedia Commons). Local communities will then be able to adopt it as their own default method of allowing uploads.
The wizard, which has been in development for a number of months, boasts a number of improvements over the existing upload form, per Erik Möller:
| “ |
|
” |
A number of bugs linger, however, and these will need to be dealt with before the UploadWizard can enjoy widespread success. For example, uploads longer than 25 minutes still fail; thumbnails for some file formats (video and audio, for instance) are not shown during the upload process; right-to-left support is far from perfect and consistent; and there are a number of other known cases where uploads will stall and the user has no option to fix the problem. The relatively low interface translation rate (as of time of writing, it has been translated fully into only 14 languages) may also be a worry for a Foundation committed to total internationalisation. There are also worries that by making it easier to upload and removing many of the "traps" of the old upload form, a higher percentage of copyright violations may go undetected. Despite these concerns, the response to the new wizard has been largely positive.
Berlin prepares for Hackathon
Next week will see the Berlin Hackathon (13-15 May). The annual event, which began in 2009, will be focussed this year on "more hacking and less talking", say organisers. Volunteer developers and Wikimedia professionals alike will come together over a number of "core" projects (excerpted from MediaWiki.org):
- "Fixing the parser. Once and for all." Programmers will look at the promise of a new parser, MediaWiki.next, with a report and demonstrations of initial work by Brion Vibber and Trevor Parscal. A hot topic for discussion is likely to be how to mark pages as incompatible with the new parser whilst retaining its core functionality.
- Sorting out how best to handle the influx of photo uploads expected as part of Wiki loves Monuments in September
- Looking at operations issues, including the new data centre, and preparing all infrastructure and services for running two data centres in parallel; the expansion of the Virtualisation Framework for better MediaWiki testing, and the rise of IPv6.
- Discussing source code version control systems and how they affect the speed and process of code review
- Improving usability/accessibility with little skin hacks
- Discussing the development of the mobile site
- Developing "an attractive and fun tool that allows users to understand how to pick a [copyright] licence".
- Pondering the future of OpenStreetMap integration in Wikimedia sites
- Participating in a general purpose "Bug hunt"
Other projects are also likely to come up during the Hackathon, including the new Narayam extension and other work done recently regarding improving the user experience of those who write in non-Latin alphabets. Historically, the meetup has provided a focal point that invigorates projects, rather than an inclusive event where projects are begun, worked on and finished. The Signpost hopes to report the success of the 2011 event in future issues.
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 many weeks.
- Gerard Meijssen blogged about improving the nature of MediaWiki's current support for both types of written Chinese (Simplified and Traditional) such that it can be ported and enabled on Wikia wikis.
- With the resolution of bug #28655,
{{#time:Y|1945}}now works properly. Other problems with the parser function remain unfixed, however, since they have their roots in the PHP programming language itself. - Gerard Meijssen interviewed former CTO and now once again paid developer Brion Vibber. Asked to comment on what non-pressing scheme he would like to work on, he responded that "the modern web has caught up with... Flash in terms of infographics, interactive timelines, maps and diagrams, and games and simulations; good collaborative tools for creating things that are both information-rich *and* move and respond to the user are still sorely lacking".
- On 9 May, version 3.0 of the Article Feedback tool will go live to 100,000 articles on the English Wikipedia (wikitech.wikimedia.org). It incorporates the new EmailCapture extension, allowing readers to provide and validate their email addresses for follow-up contact.
- Users experienced intermittent problems this week with the colouration used for diffs. The problem is likely the result of one server getting out of sync with the rest of the "pool" that handle requests. Developer Roan Kattouw said on the Server Admin Log that he "thought we [the Foundation] had measures to prevent out-of-sync servers from being pooled?"
Discuss this story
The official announcements for the UploadWizard and the Article Feedback Tool are now up on the WMF blog: "A new way to share pictures, sounds and video" / "Expanded Use of Article Feedback Tool". Regards, HaeB (talk) 01:53, 10 May 2011 (UTC)[reply]
"A number of bugs linger"—so the WMF is like Microsoft, eh? Push out the cool stuff first and fix the bugs later. /ƒETCHCOMMS/ 18:09, 10 May 2011 (UTC)[reply]