Iframe bugs
The usability initiative recently deployed some changes to the beta features, most notably the replacement of the textarea on the edit page with a content-editable iframe (mistakenly referred to as a “rich text editor” by some users). Users at various wikis have reported some issues resulting from this change. We’re fixing these bugs as fast as we can and deploying fixes as soon as possible (once properly tested of course). Below is a list of bugs associated with the rich text editor and their status; we’ll keep this page up to date as we push out fixes. If you’re bothered by these bugs and don’t want to wait for fixes, you can turn off the iframe by leaving beta (click the “Leave Beta” link at the top of any wiki page).
Roan Kattouw (Catrope)
- bug 22311 (Pressing tab in edit box should go to summary box): fix deployed
- bug 22393 (Charinsert tools at the bottom of the edit page and old toolbar don’t work): fix deployed. Charinsert may have to be fixed in site JS on some wikis, depending on the local Charinsert implementation; this has been done on the English and Portuguese Wikipedias as well as Commons; I checked the other top 10 Wikipedias but they didn’t need a local fix. You may heve to Shift-Refresh for this to work on Commons.
- bug 22394 (Pasting formatted text preserves formatting): fix ready, needs more testing.
- bug 22398 (Extra line breaks inserted when pasting text)
- bug 22402 (Leaving beta doesn’t turn off experimental features like TOC and dialogs): fix deployed.
- bug 22413 (Old toolbar disappears when TOC enabled): inadvertently fixed when bug 22393 was fixed (love it when that happens)
- bug 22428 (Line breaks in pasted text not saved in Safari, Chrome): unconfirmed fix in SVN.
- bug 22435 (Literal and <p> in article text gets removed on save): fix deployed.
- bug 22440 (Random cursor jumps in Firefox on Ubuntu)
Tech folk will again meet in Berlin
Developer Meet-Up (by Raymond, CC-BY-SA)
Wikimedia Germany invites all MediaWiki developers, Toolserver users, Gadget hackers, and other people interested in the technical side of Wikimedia projects to come to Berlin for a Developer Meet-Up on April 14.-16. Last year’s meet-up in Berlin was a great success, and we hope to make it even better this time! This year we want to focus on structured (meta) data, search, and community building. The future of the Toolserver will also be a subject.
The dates are set, but it’s not clear yet if we start full throttle on Wednesday the 14th or if we have just an arrival event on that date and a full day on Friday the 16th instead – this depends on venue arrangements that are not sorted out yet. Note that registration in advance will be required – a website will be set up for this soon, we will announce it on blogs and mailing lists.
On that Friday, April 16., the Wikimedia Chapters and Board start their convention in Berlin. This will be a great opportunity to meet, to discuss interesting topics, to network and to exchange ideas and thoughts! Wikimedia Germany will host the event, so we will organize the venue, the hotel(s), some fun things to do in Berlin, food & drinks and lots of other things – and there might even be a party at the c-base again…
See you in Berlin!
Wikimedia donates servers to deserving non-profits.
Posted by RobH in hardware, open-source, wikimedia on February 3rd, 2010
Every year, Wikipedia usage goes upward, and every year the technical folks working and volunteering with Wikimedia have to plan, purchase, and implement new servers to keep up to the growing popularity of Wikipedia and its sister projects. With the advances in computing, running 9 new application servers this year took the load of 36 application servers from 3 years ago.
So when we upgrade, what happens to the old equipment that is too slow for Wikipedia, but not too slow for MANY other non-profits? We donate them! These systems were 1U rackmount servers, dual cpu 2.5-3, single core, 2-4GB of RAM, and 2-4 HDD Bays with 1-2 80-250GB HDDs. This year, we have three non-profits who received our older systems (in alphabetical order): Drupal.org, OpenStreetMap Foundation, and Sugar Labs.
Drupal is a free software package that allows an individual or a community of users to easily publish, manage and organize a wide variety of content on a website. Tens of thousands of people and organizations are using Drupal to power scores of different web sites.
The OpenStreetMap Foundation is an international non-profit organisation supporting but not controlling the project. It is dedicated to encouraging the growth, development and distribution of free geospatial data and to providing geospatial data for anybody to use and share.
OpenStreetMap is an open initiative to create and provide free geographic data such as street maps to anyone who wants them.
The mission of Sugar Labs® is to produce, distribute, and support the use of the Sugar learning platform; it is a support base and gathering place for the community of educators and developers to create, extend, teach, and learn with the Sugar learning platform.
We hope the recipients of our servers will be able to put them to good use!
Below are some common questions involving Wikimedia and the server donation process:
Q. How can I get some of the decommissioned donation servers?
A. The best place to follow the goings on of our technical team is here, on the Wikimedia Technical Blog. When we have a batch of servers up for decommissioning and donation, we will announce it on the tech blog, and instructions on how to apply to receive some servers.
Q. Who is eligible to apply for servers?
A. We try to only donate servers to other non-profits whose core values are similar or in support of our own. This means we do not donate them for individual use. Since these servers were purchased with donations to support Wikimedia, we feel we need to further donate them to other like-minded organizations, since that is how the money for the servers was meant to be spent.
Q. How often does this happen?
A. Most servers are kept in use by Wikimedia beyond three years. Many of our servers that we have turned off in this batch are anywhere from 3 to 5 years old. We only replace them when it makes sense from the technical standpoint to do so. This means we cannot just say ‘we will do this every X months.’ We try to get the most use out of every server, as they were donated or purchased with donations. So there is no set date, just keep checking the Wikimedia Technical Blog, when we have more to donate, we will say so there!
Q. I am a student/person/so and so, and I want to learn to develop and do such and such. Can you send me a server?
A. Sorry, unfortunately it is just not realistic or fair of us to try to sort out which personal use requests for servers are legitimate and which are folks wanting computers for any other reason. We choose to limit our donations to other like minded non-profit organizations.
Rob Halsell
Systems Administrator
Deployment of Babaco Enhancments
Posted by Trevor Parscal in mediawiki on January 27th, 2010
The Usability Team is preparing a supplemental release which will bring more stability and functionality to the features of their Babaco release, which has been available to logged in users of Wikimedia sites since October 2009. Among the changes which have been made are many improvements in interactivity and aesthetics, but the most critical change is using an HTML iframe element together with a special design mode that modern browsers support, in favor of the previous HTML textarea. This paves the way for developing a rich editing experience with collapsible templates and syntax highlighting, as well as provides a foundation on which a WYSIWYG editor may eventually be built upon.
The table of contents, which now features controls for expanding, collapsing and resizing, is also much more accurate than before. The link dialog which once had a tabbed interface for making internal or external links now intelligently detects the type of link you are making, an improvement we designed and prototyped while literally watching users struggle with the software during usability testing. Finally, there is now support for language specific icons in the toolbar, with a several languages ready to go such as German, French, Spanish, Dutch, Portuguese, and Polish. This feature allows us to provide a more native experience by using language specific mnemonics. So far we’ve applied this feature to the bold and italic buttons, which are now B and I for English, F and K for German and G and C for Spanish. Languages without customized icons will continue using A and A.
The team will be deploying these upgrades in the coming days. To learn more about the Wikipedia Usability Initiative, check out their website at http://usability.wikimedia.org.
Bugzilla upgrade.
Posted by aZaFred in linux, open-source, wikimedia on January 18th, 2010
Thanks to Priyanka’s wonderful work in theming Bugzilla and ironing out the last couple bugs and extensions, we are finally ready to move on with the upgrade.
As a side effect, Bugzilla will be down for a couple of hours (let’s say 2 to be on the safe side) around lunch-time. (Edit Addition: 2010-01-19 between 20:00 GMT and 22:00 GMT)
Flagged Revisions: Your questions answered!
Posted by William Pietri in mediawiki, wikimedia on January 6th, 2010
There has been a lot of interest lately in Flagged Revisions, a quality control mechanism for MediaWiki. In particular, people want to know when and how that’s getting used on the English language Wikipedia.
I’m William Pietri, a San Francisco software consultant who recently came on part time to do project management for this. In addition to my long experience building web software for on-line communities, I’m also a Wikipedian. Although I haven’t done much more than small corrections lately, I started editing in 2004, and became an admin in 2007.
My job on this has two main parts. The first is to make sure that everybody working on this gets everything they need to make progress. The second is to communicate progress to the wider world. In the spirit of open communication, this is an update in question-and-answer form. Mostly from real questions people have actually asked me, but I’m going to sneak in a couple that I expect somebody will ask shortly.
What is Flagged Revisions?
You can find more detail here, but Flagged Revisions is basically a way to insert a quality review step between someone editing an article and that article version being published for the general public to see. It has been in use on the German Wikipedia since May 2008, and implemented in other languages and projects since then (see this page on Meta for a full list). Typically, in those use cases, every single article is treated in this way, and every change by a new user has to be reviewed. There are a number of ways Flagged Revs can be used, and the proposed implementation for English Wikipedia (described below) is quite different.
Fundamentally, the objective of this technology is to reduce the exposure of readers both to subtle and not-so-subtle malicious changes in articles (whether it’s the insertion of blatant nonsense, or claiming the death of a celebrity), and to reduce the workload of people patrolling these changes by reducing duplication of effort.
What about the English language Wikipedia?
The use of Flagged Revisions on the English Wikipedia has been under discussion for a long time. Ultimately, the English Wikipedia volunteer community developed a proposal titled “Flagged protection and patrolled revisions“, which garnered strong support. It is fundamentally different from the way the technology has been used so far. Instead of requiring every change by a new or untrusted user to be reviewed, the mechanism would be activated on a per-page basis only, as an alternative to existing tools to restrict editing.
Notably, thousands of articles in the English Wikipedia, typically pages with a very high risk of malicious editing (e.g. major political figures), are currently “semi-protected”, meaning that new or unregistered users cannot make any changes at all. This new tool would make it possible to open up these pages for editing, provided that potentially problematic changes receive positive review. As a result of the more open approach, more high-risk pages could be made subject to this level of community moderation.
Initially, the English Wikipedia volunteer community wants to trial the system for two months. In addition to this alternative to page protection, the proposal calls for implementation of a new feature called “patrolled revisions”, which doesn’t impact what readers see, but is designed to make it easier for change patrollers to organize their work.
How is the Wikimedia Foundation responding to this proposal?
The Wikimedia Foundation (WMF), together with Wikimedia Germany, has driven and funded the development of the FlaggedRevisions technology since 2007 to the point where it has been able to scale to more than a year of production use in our second-largest project, the German language Wikipedia. WMF has carefully reviewed the English Wikipedia proposal, and allocated resources to assess its impact and support implementation along the principles outlined in the proposal.
The technology as proposed markedly differs from the way it’s been used before, so it’s a substantial development and design effort to get it right. For example, the notion of a per-page setting necessitates an entire set of user interface changes that allow changing the setting of a page, and that make it clear to a reader what the state of a particular page is. See this mock-up by Howie Fung as an example of what revised per-page controls could look like. WMF will post further mock-ups for feedback and prototypes for testing as they are built.
Who is currently working on the project?
- Aaron Schulz, a contract developer with Wikimedia, is the lead developer of FlaggedRevisions.
- Howie Fung, a contract product manager who also works with Wikimedia’s Usability Initiative, is supporting usability and product review of the software.
- I, William Pietri, support the project management of the English Wikipedia roll-out as described above.
- Erik Zachte, Wikimedia’s Data Analyst, will develop metrics specifically assessing the impact of the English Wikipedia rollout.
When will it be done?
This question has been asked a lot lately. Because this isn’t the flipping of a switch but a software development project, answering it requires me to let you in on a secret about software development projects. There are basically four ways to deal with dates, but only three of them are sane:
- It’s done when it’s done. Nobody mentions dates. The developers code until they’re finished. Then you release, get feedback, and code some more.
- Measure progress and project dates. You lay out all the work, estimate relative size, and then measure how much you get done over time. That data is used to figure out release dates.
- Pick a date and release whatever you finish. If you’re building, say, annual tax return software, it’s better to ship on time and drop features than it is to finish late with everything.
- Make up dates to please people. This is very popular, and has the advantage of making people happy at first, but it rarely works out well.
Until recently, we were using the first approach. That’s how most Mediawiki development (and most other open source development) works, and it has many advantages. But because a lot of people are eager for this project to launch, we’re shifting to the second approach.
The developer, Aaron Schulz, has estimated all of the items on the work list and already started in on them. The holidays complicate things some, but I expect we’ll have enough data to make a first guess at the estimated release date by the middle of January.
Wait, there’s only one developer on this? Is the Wikimedia Foundation taking this seriously?
Yes, absolutely. Aaron has been working on the Flagged Revisions extension for years, and nobody knows it better. We talked about adding developers, but unfortunately adding more people now wouldn’t help. I haven’t dug into the history much, but it looks like the real slowdown lately wasn’t in the coding; it was in turning the many-voiced community response into a clear set of things to do.
Having spent time with all the people involved, it’s clear to me that the Foundation takes this project very seriously. It’s one of small number of high-priority projects, which include things like keeping the site running, organizing the annual fundraiser, and Wikimedia’s usability initiative.
How can I keep track?
There are a few ways. First, we’ll mention big updates (and the eventual release) here on this blog. Second, keep an eye on the labs site. That will be updated regularly with the latest code and configs. You can judge for yourself how we’re doing, and make sure we do it right. And third, I’ve put the work queue into a public web-based tool called Pivotal Tracker. It’s one of the few software project management tools made for the measure-and-project approach we’re using; if you’re the sort of person who likes way too much detail, you can find real-time updates there.
How can I get involved?
Go to the labs site, play with the current implementation, give feedback, post your own user interface design suggestions, report bugs, and so forth. Further community discussion in the English Wikipedia about the proposed roll-out is happening on the page about flagged protection and patrolled revisions. I’m always glad to hear feedback, either on my talk page or via email. And of course, you can comment on this very blog post.
William Pietri
Contractor, Wikimedia Foundation
Priyanka Dhanda joins Wikimedia tech team
I’m very pleased to welcome Priyanka Dhanda to the Wikimedia Foundation as Code Maintenance Engineer. Priyanka joins us from SourceForge Inc., where she worked since 2002 as a software developer and also was involved in operations, working on most pieces of the infrastructure, and integrating third party software with the SourceForge platform (including MediaWiki). Priyanka holds a Master’s Degree in Computer Science from the University of Toledo, Ohio, and a Bachelor of Technology in Computer Science and Engineering from the Pondicherry Engineering College in India.
She is starting today and will work in the San Francisco office.
Priyanka will be a key interface between software developers and the operations team, helping us to catch up with our code and bug review backlog, to mentor new developers, to push projects to completion, and to improve testing and automation. Please don’t swamp her immediately with requests as she’ll need some time to get more deeply oriented in the MediaWiki codebase. :-) You’ll be seeing her in the IRC channels, on SVN, Code Review, BugZilla, wikitech-l, and so forth.
Please join me in welcoming Priyanka to the Wikimedia team! :-)
– Erik Moeller
Deputy Director, Wikimedia Foundation
LiquidThreads almost ready to deploy
Hi all,
With the Foundation’s support, I’ve spent the last few months churning away at LiquidThreads, a new discussion system that is proposed for use on Wikimedia projects.
Essentially, it’s an attempt to marry the radical openness of the wiki paradigm with the usability and practicality of a forum-like system. As the name implies, LiquidThreads is designed to allow any user to easily refactor discussions while maintaining edit history, to edit other users’ comments, and to collaborate on a summary of an ongoing discussion. LiquidThreads also brings many standard communication features lacking from wiki discussion pages, such as watching and protecting individual discussion threads, RSS feeds of comments in a discussion or on a discussion page. In the world of online communication, its approach is entirely unique.
LiquidThreads has been in alpha testing on Wikimedia Labs for several months, and, more recently, it’s been used in a production context on the strategy wiki, where it has been quite well-received. It’s been easy to run these smaller trials, as the extension allows the activation and deactivation of LiquidThreads discussions on individual pages with a simple parser function.
While there are still some issues remaining before wider trials, I believe I can resolve most of them quite quickly (within a few weeks when my vacation finishes at the end of next month), and I’d like to get the ball rolling in proposing small-scale trials on some of the larger wikis, so that a full discussion can be had, and so that adjustments can be made on the basis of ongoing feedback. I’d especially like to see LiquidThreads used on some of the higher-traffic discussion pages on English Wikipedia (such as the technical village pump), and progressive rollout on some of our mid to large sized wikis.
So, I’d like to encourage you to have a play with LiquidThreads, either on the strategy wiki or on the test site (which generally runs a newer version). Tell me what you like about it, and (far more importantly) what improvements you think it needs before we can expand our trials to wider parts of the Wikimedia Universe, and perhaps move towards a full rollout of this very exciting technology.
I should give the following caveats about LiquidThreads as it stands. These are all issues that I intend to address before any trial expansion occurs.
- Presently the system is somewhat vulnerable to abuse. I intend to make changes to the way signatures work, and improve tracking and listing of thread actions by specific users.
- While LiquidThreads allows for thread summaries and discussion headers, the system does not currently have support for collaboratively-edited posts which are unsigned or signed by a group of people. These are a key piece of any decision-making framework, and I intend to make adjustments to make this possible.
- There is no support for embedding LiquidThreads discussion pages on other pages.
- There are plenty of minor interface issues which I intend to clean up.
Feedback is best directed to the dedicated feedback page, or, alternatively, to bugzilla (although before filing a bug, you should check the list of existing LiquidThreads bugs).
Thanks,
Andrew Garrett
Software Development Contractor
Mobile Homepage in your Language!
Posted by Hampton Catlin in mobile, software on December 9th, 2009
Setting up mobile home pages for different languages is a very important part of my job here at Wikimedia. The English mobile home page has been setup for a while and it is based on CSS selectors. A couple other languages, (like Spanish) were easy to implement CSS solutions for and therefore I had gone ahead and created mobile home pages with the help of those communities. However, I am only one man and manually contacting each Wikipedia admin structure individually was taking far too long. Besides, different languages have different items on their home page!
With the help of Petter Strandmark at the Swedish Wikipedia, we have come up with another method that should hopefully work better for lots of different languages: A customized mobile home page. If you want a mobile home page in your language, just send us the name of the page and I’ll wire it up. You can see this is the Swedish mobile main page and here is the corresponding specialized mobile home page on the main site.
It’s one of those obvious solutions that takes way too long to come up with… but at least we have it now.
Now, each community can build the mobile homepage that they are looking for and maintain it themselves with whatever content they want.
If your language wants to produce a mobile home page, then open a ticket in Bugzilla that includes the URL of an already setup MainPage version and I’ll sort it out!
Cheers!
Fun with Subtitles
Posted by Michael Dale in wikimedia on November 9th, 2009
You can select your subtitle language
We have just finished up the Multimedia Usability Project Meeting here in France. I am sure there will be more general wrap up coverage of the meeting shortly… but I wanted to share a hack we worked here.
For a long time people have requested subtitle support for mediaWiki embed videos and at this meeting we were finally able to sit down and hack up an initial solution. The system works by putting the srt files into the wiki so people can collaborate on translation and contribution. The naming scheme is “TimedText” followed by the file name followed by the language code followed by .srt . We include a basic editor to upload srt files and switch between between languages. We presently display the subtitles on the side of the video but they should make there way below the video soon. There are lots of supporting projects to work on if anyone is interested ;)
How do I try it out
To try it out install the mwEmbed gadget and then visit either video linked to in this post. Hopefully we can produce some more documentation soon :)
Some quick ideas for enhancements ( I am sure you can think of some too) :
- A translation interface maybe borrowing from the techniques used on translatewiki.net
- A simple search of subtitles from the current video
- A more complex search system for subtitles across all videos
- Timed metadata a-la-metavid
subtitles on commons using the mwEmbed gadget
Localization Update: As mentioned in the comments we are still missing some of the localizations msgs. They should be making their way in there soon, along with some other updates.
Usability Beta Enhancements
New watch/unwatch and cascading tabs
Thanks for trying out the usability beta. Close to 280,000 people tried out the usability beta and about 220,000 people continue using it. One of the most-frequently reported frustration about the beta was that (1) watch/unwatch was hidden under the drop-down menu and (2) tabs overlaps when the browser is scaled down or the resolution is low. Tab issues were more significant for language communities whose words tend to be long such as German. We are also simplifying the search box to simplify the interface and in order to minimize the overlapping side-effect. Those new features are currently staged on the prototype wikis in English, German, Japanese, Arabic, Serbian, Russian, and Sinhala. You need to log-in in order to see watch/unwatch tabs. The screenshot on the right is the shot when the browser window is scaled down to 640×480. “View History” is moved to drop down menu in order to keep “Read” and “Edit” tabs visible. Let us know your feedback here.
- Naoko
Update on November 18th: Thank you for your support and feedback. These features are now available in the usability beta across all Wikimedia projects.
Wikipedia Mobile October Update
Posted by Hampton Catlin in mobile, software on October 12th, 2009
We have a lot of cool stuff that got pushed out today. I’m really excited to tell you about it. First of all, Derk-Jan Hartman (github: hartman) has been hard at work bringing us NetFront support. NetFront is the HTML rendering backend to many devices. Here is a list of the devices that Derk’s hard work has given us blessed access to.
- Most SonyEricsson Phones
- Nintendo Wii
- Sony PS3
- Sony PSP
He’s also working on Opera Mini support and has done a lot of awesome refactors on the code. Fixing many an embarrassing lines of code for me. Its great to see other people chipping into the project and I know for me personally, its a big inspiration to see people giving their time to help this project out!
Now, on to a small tweak that we made to the subcategory expansion system. Its a really small change, but should make using the app even easier. If you want to expand a subcategory, clicking on the title of the category gets the job done. No more having to aim your finger at the “Show” button. Obviously, it also hides if you do it when the section is visible. Its these types of changes that are my favourite. Someone might not even notice it, but it should make their usage of the site a litttttle bit easier.
We’ve also done various and sundry internal changes. We got a patch from Jacques Crocker to use Bundler to manage our Gems. Getting the capistrano part right on that was a bit difficult and so we had a little downtime today while I was working out those kinks. But, from now on, it should be much, much easier to get a local copy of Wikimedia Mobile up and running on your system.
We’ve also expanded the number of supported languages recently. All of this is thanks to the tireless work of Niklas Laxström and others from the TranslateWiki project. They were very helpful in building an API for us to import new languages. I wrote a couple rake tasks and Ruby bits to make it all go. So, now all you have to do is type `rake lang:import` and it will download the freshest strings you’ve ever parsed.
Here is an updated list of all of the languages we support: af, ak, ar, az, bg, bn, br, bs, ca, cy, de, dsb, el, en, eo, es, eu, fi, fr, gl, gv, he, hi, hr, hsb, hu, ia, id, is, it, ja, ka, km, kn, ko, ksh, kw, lb, li, lv, mg, mk, mt, nl, no, oc, pl, pms, ps, pt, ro, ru, sah, sh, sk, sl, su, sv, te, th, tr, uk, vec, vi, wo, and xal. I really have no idea what most of those languages are, but I’m also super happy to support them. And, I’d like to welcome the newest member to our class: Akan (ak), comes to us from Ghana! I know, cool right? Technically, its not a language but an Ethnologue. (Must stop myself from reading too much about this on Wikipedia… and finish this post)
Well folks, that’s it for the moment. Now that I’ve completed my move to another continent you should be seeing a lot more updates coming through on the mobile site. I’m really excited about where we are going and I’m also excited to reveal the results of our survey in the next couple weeks. Some really interesting and exciting things in there!
New Media Features Gadget
Posted by Michael Dale in wikimedia on October 10th, 2009
I would like to announce that some of the new media features are now available in gadget form on Wikimedia Commons and the English Wikipedia. These include a new ogg player, the add media wizard, and firefogg upload support. I hope having these components in gadget form will enable some more testing and feedback :)
Getting Started to enable these components you must turn on the mwEmbed gadget. You can turn it on by visiting your preferences page. Once you enable the gadget you should shift reload to ensure you have a fresh copy of the JavaScript. (note you will need to enable the gadget for each wiki you want to test (ie both for wikimedia commons and Wikipedia). Once enabled you can check out the following features: Read the rest of this entry »
Click Tracking on Edit Toolbar deployed
After many a hearty SQL battle, we finally have click tracking deployed on the wikimedia projects!
Data on button usage
What’s being tracked?
Which buttons are clicked on the toolbar during editing
What information is being recorded?
The button clicked, the time of the click, total edit count of the user clicking, and edit count for the last 1, 3, 6 months
What information is NOT being recorded?
Individually identifiable information of any sort (eg who exactly clicked what) and anything that would violate our privacy policy in general
Why?
As we revamp the UI, rather than randomly throwing buttons up there we think are pretty (we think they’re all pretty), we thought we’d put buttons up and features that people actually use. Novel, right?
What about the edit history and stuff?
We figure the way a novice editor uses the toolbar is different form a ‘power’ editor, and that there’s probably some gradation in between. Is there? Well, that’s what we hope to find out…
–Nimish
Image renaming fix
Fixed an ugly internal caching bug which could break renamed image redirects on Commons being accesses from other non-English sites. Hopefully that’s most of those solved now. :)
SVG in Wikipedia and Wikimedia Commons
Slides for my talk at SVG Open available for download as PDF or Keynote source. (I can make my test corpus available as well — let me know if interested!)
– brion
Babaco is ready for tasting
Preview of the second set of usability features, Babaco, are available through user preferences. The first feature is the article outline in the right hand side of the editing area. The outline updates itself in real-time as you type the headers in the articles and provides links which when clicked will jump you to the start of each section in the article. The second feature is the assisted way to insert links and tables. Instead of inserting wiki syntax, a dialogue box pops up when you hit the link icon in the toolbar. For internal links, link suggest features offers auto-complete options and validate the existence of articles. A click of the table icon in the toolbar will also assist define the number of rows and columns without modifying table rows and columns in the wiki syntax. Thirdly, new search and replace dialogue is added to the advanced toolbar. These features are released in the stealth mode, which means users need to turn them on by going to user preferences. To enable these features, please go to “My Preferences”, select ‘Editing’ tab and enable the features listed under ‘Experimental features’. We, the usability team, is still refining look and feel, but we wanted to invite active users to start using these features and provide us feedback.
Known Issues: Accuracy of cursor positions using the article outline feature (aka Navigable Table of Contents) degrades in long articles and significant so if you use Firefox. We are also still working on the display issue of NTOC in Firefox2 on Vista. Bug 20669
The release details and discussion can be found in the Babaco discussion page of the usability project wiki. Looking forward to receiving your feedback.
- Naoko
Navigable Table of Contents
Inserting link using link dialogue
SVG Open
Posted by brion in open-source, wikimedia on October 2nd, 2009
I’m hanging out down in Mountain View for the SVG Open conference this weekend, to speak a bit on how we use and plan to use SVG at Wikimedia and to get up to date on the state of the art. I’ll post my full talk slides on Sunday after my talk…
One of the most exciting new developments in the SVG world right now is svgweb, a very cool tool which brings high-quality SVG rendering support — including full support for the SVG DOM and interactivity — to any browser that supports Flash. This essentially fills the “SVG gap” for most Internet Explorer users, which opens up a huge world of possibilities for both interactive content and tools for building, editing, and localizing SVG-based diagrams, charts, maps, etc right in the browser.
Google web standards evangelist Brad Neuberg gave a great talk about the background of how something like svgweb was needed and showed some great demos, including a quick preview of an inline SVG pan-and-zoom tool for Wikipedia / Wikimedia Commons; we’ll have some even funner demos based on that Sunday!
Also saw a good talk from Sam Ruby on some of the gotchas in the current state of HTML vs XHTML vs HTML5 and how SVG is (or isn’t) supported in various profiles and various browsers. Most interesting was his proposal to rethink how we deal with markup validators in the webdev world — right now most validators give you a lot of errors about things that don’t really make a difference (font vs style?), but freely ignore problematic but “legitimate” structures (say, unclosed list items).
MediaWiki’s new discussion system in testing on Wikimedia Labs
Posted by andrew in mediawiki, software, summer of code, wikimedia on October 1st, 2009
I’m very excited to announce that LiquidThreads, the next-generation discussion system that I’ve spent the last few months developing for the Wikimedia Foundation, is now in beta testing on liquidthreads.labs.wikimedia.org.
Sample of the LiquidThreads interface
Wikimedia XML data sets released on Amazon Public Data Sets
For our community members that do analysis on Wikimedia project data, I’m happy to announce the release of our XML snapshots within Amazon Public Data Sets.
http://aws.typepad.com/aws/2009/09/new-public-data-set-wikipedia-xml-data.html
To those curious about why this happened … earlier this year I had gotten approached multiple times from researchers and community members wanting to parse our data but frustrated at the costs and time of doing it on their own infrastructure.
Many of them were already familiar with academic computational clusters and were wondering if there were any similar solutions available for them to do large scale processing. The tool sever was one option but sometimes it didn’t provide the level of flexibility that they needed and/or their projects were too computationally intensive to run alongside other tasks.
Instead I mentioned that I had already been thinking of pushing our data sets in the Amazon cloud as they had a wealth of the infrastructure in place and had an infrastructure that our users who were familiar with.
Fast forward to now, we have our first release ready to be worked on and I’m sure that we will hear back about new and exiting discoveries that our communities make.
This isn’t the first Wikipedia data set to exist in Public Data Sets but it will be the first that Wikimedia is committing to supporting on a regular release cycle. Amazon will be picking it up every month and retaining copies for at least three months.
I’m excited to see the stats of how many people use it.
–tomasz
Supporting translatewiki.net
Translatewiki.net is a core part of the MediaWiki ecosystem. While not a Wikimedia Foundation project, it’s used by hundreds of volunteers to improve the localization of MediaWiki and its extensions, alongside other open source projects, which has led to MediaWiki being one of the most internationalized software packages available.
We’re very pleased to be able to recognize the incredible volunteer efforts behind translatewiki.net at least in a small way. Starting tomorrow, Siebrand Mazeland will be able to devote one day a week to the support of the project on a contract with the Wikimedia Foundation. We’ve identified core priorities for the next year as an increase in the number of volunteer developers supporting the translatewiki.net infrastructure, and the number of volunteer translators working on localization for the most widely spoken languages.
Welcome, Siebrand, and a big thank you to the entire translatewiki.net community for their work. :-)
Erik Moeller
Deputy Director, Wikimedia Foundation
FlaggedRevs test wiki awaits you!
Apparently due to some miscommunications, a lot of people didn’t realize that the FlaggedRevs labs test wiki has been active and waiting for people to poke at it for a month, since just before Wikimania!
We need interested people to be get up as local administrators to try out the the per-page stabilization settings (accessed via the ‘protect’ tab); by default most pages do not activate FlaggedRevs in the configuration we’re testing for English Wikipedia.
I’ve added a couple quick notes to this affect on the main page.
Update: We’re collecting some folks to be bureaucrats and help set up more test admins so we can get things going quick!
Announce: Brion moving to StatusNet
I’d like to share some exciting news with you all… After four awesome years working for the Wikimedia Foundation full-time, next month I’m going to be starting a new position at StatusNet, leading development on the open-source microblogging system which powers identi.ca and other sites.
I’ve been contributing to StatusNet (formerly Laconica) as a user, bug reporter, and patch submitter since 2008, and I’m really excited at the opportunity to get more involved in the project at this key time as we gear up for a 1.0 release, hosted services, and support offerings.
StatusNet was born in the same free-culture and free-software community that brought me to Wikipedia; many of you probably already know founder Evan Prodromou from his longtime work in the wiki community, launching the awesome Wikitravel and helping out with MediaWiki development on various fronts. The “big idea” driving StatusNet is rebalancing power in the modern social web — pushing data portability and open protocols to protect your autonomy from siloed proprietary services… People need the ability to control their own presence on the web instead of hoping Facebook or Twitter always treat you the way you want.
This does unfortunately mean that I’ll have less time for MediaWiki as I’ll be leaving my position as Wikimedia CTO sooner than originally anticipated, but that doesn’t mean I’m leaving the Wikimedia community or MediaWiki development!
Just as I was in the MediaWiki development community before Wikimedia hired me, you’ll all see me in the same IRC channels and on the same mailing lists… I know this is also a busy time with our fundraiser coming up and lots of cool ongoing developments, so to help ease the transition I’ve worked out a commitment to come into the WMF office one day a week through the end of December to make sure all our tech staff has a chance to pick my brain as we smooth out the code review processes and make sure things are as well documented as I like to think they are. ;)
We’ve got a great tech team here at Wikimedia, and we’ve done so much with so little over the last few years. A lot of really good work is going on now, modernizing both our infrastructure and our user interface… I have every confidence that Wikipedia and friends will continue to thrive!
I’ll start full-time at StatusNet on October 12. My key priorities until then are getting some of our key software rollouts going, supporting the Usability Initiative’s next scheduled update and getting a useful but minimally-disruptive Flagged Revisions configuration going on English Wikipedia. I’m also hoping to make further improvements to our code review process, based on my experience with our recent big updates as well as the git-based workflow we’re using at StatusNet — I’ve got a lot of great ideas for improving the CodeReview extension…
Erik Moeller will be the primary point of contact for WMF tech management issues starting October 12, until the new CTO is hired. I’ll support the hiring process as much as I can, and we’re hoping to have a candidate in the door by the end of the year.
– brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
San Francisco
Update: Evan’s announce is up on the StatusNet blog.
Theora 1.1 Released
Posted by Michael Dale in wikimedia on September 28th, 2009
Theora 1.1 has been released
Theora 1.1 has been released. This release reflects the efforts of xiph.org developers who over the past year have done incredible work to greatly improve the core free codec video library. This effort has been support by Mozilla Foundation, Red Hat and others. These improvements include:
Chris Blizzard from Mozilla has a detailed blog post about the improvements and what they mean for open video creators, distributors and viewers. Wikimedia foundation makes exclusive use free/open formats and has been a long time supporter of ogg theora and makes use of the free codec in its websites. Wikimedia also helped organize some improvements by administrating a theora improvement grant from Mozilla earlier this year.
Also a new version of ffmpeg2thora has been released using this new codebase making it easy to take advantage of these new features. If you would like to give the new encoder a spin you try it out with the web based firefogg encoding app.
LocalisationUpdate in testing
Ok, we still need to complete automation of update runs for LocalisationUpdate, but it seems to be working!
It’s not the most glamorous of extensions, but you can see here an updated message (“Den här sidan” where the current deployed message file says “Denna sidan har”)!
– brion