Wikipedia:Wikipedia Signpost/2010-11-29/Technology report
Bugs, Repairs, and Internal Operational News
Should Wikimedia Commons host .zip files?
Late October saw a discussion on the Wikitech-l mailing list about whether allowing users to upload their own .zip files was desirable and/or possible from a technical point of view. Since Wikimedia has a strict anti-proprietary and generally pro-standardisation mission, files with direct use (e.g. .svg files) have tended to be given priority over files that are useful only for editing purposes (e.g. .ai files). Since these do have a use in terms of Wikimedia's wider vision of enabling the free sharing of information, it was proposed that the upload (and download) of zipped bundles of these files be allowed. Generally, broadening the ranges of files users could upload to Wikimedia sites could also prove useful on projects such as Wikibooks, by allowing interactive examples. It was also pointed out that some of these files may have a direct use in future, if only a proper extension were built into the MediaWiki software.
Former CTO Brion Vibber summarised the concerns about this approach when he wrote:
| “ | In all cases we have the worry that if we allow uploading those funky formats, we'll either a) end up with malicious files or b) end up with lazy people using and uploading non-free editing formats when we'd prefer them to use freely editable formats.... I don't really relish the thought of checking image source data for warez archives. | ” |
Last week, the Wikimedia Foundation's Deputy Director Erik Möller restarted the discussion with reference to a new Commons proposal: Commons:Restricted uploads. In general though, the technical concerns about the idea were substantial. MZMcBride, for example, noted that the solution was "horribly hackish".
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.
- On the strategy wiki, Deputy Director Erik Möller this week posted a proposal for a "Media review" toolset that would allow easier importing of images from free content sites such as Flickr or PLoS, or various Smartphone apps. This would utilise the new upload wizard's temporary "stash" are to transfer new media using interface plug-ins hooked into sites' APIs, etc., onto Commons for review and annotation before being finally published.
- Block expiry times are now available via the API (bug #26089), as are the number of pages in a given DjVu file (bug #26125).
- With changes resulting from bug #21911, the role of the warning message "This page is x kilobytes long, some browsers may have problems editing pages approaching or longer than 32kb." is evolving. Specifically, now that the share of browsers with that 32kb limit has shrunk to an almost negligible level, some people are arguing that it would make more sense to use the warning to direct users to Wikipedia:Article size where the page size exceeds 70 or 80kb.
- Special:Mypage and Special:Mytalk are going to support the oldid, diff and dir parameters when used inside a URL - e.g. http://en.wiki.x.io/w/index.php?title=Special:Mytalk&diff=cur will point to the latest change on a logged-in reader's talk page (bug #25829).
Discuss this story
Regarding the file type proposal, the intent here is to significantly expand the number of file types that we can at least store. For many files such as 3D images or layouted documents, we currently can't retain source information at all, which dramatically limits reusability of content on Wikimedia Commons. Yes, restricting uploads to a trusted subset of users has large drawbacks, but so far no solution has been proposed that could be implemented with reasonable effort to achieve a comparable or better outcome. I've written a bit more here, and have tried to cover some of the alternative approaches in the proposal itself. At the end of the day, I'm happy to support any near-term solution which achieves the same outcome: allowing us to consistently retain source data for uploaded files.--Eloquence* 20:31, 29 November 2010 (UTC)[reply]