I recently had to investigate how to customize the “meta” widget provided by WordPress.

I maintain the Wikimedia Blog, and we wanted to include a link to our posting guidelines to the “meta” section of our sidebar.

There is no straightforward way to do this; the widget can’t be edited from within the admin area.

One possibility was to replace the standard meta widget by a custom text widget, with the same content and links, and to add our guidelines to the mix. But this meant losing the nice context-aware links (e.g. “Register” vs. “Site admin”, and “Log in” vs. “Log out”, respectively for logged-out and logged-in users) provided by built-in WordPress functions (wp_register and wp_loginout): widget text can’t embed PHP code.

Another possibility was to install a third-party plugin to customize the meta widget (or allow PHP code in widget text). I’m usually reluctant to using plugins for simple changes like the one we wanted to do. Both our Operations staff and I prefer to keep the amount of third-party plugins installed on the blog to a minimum, for various reasons (security, maintenance, maintainability, etc.)

Because there are no hooks to plug into the widget’s behavior, most of the solutions I’ve seen online consist either of using a third-party plugin, or messing with WordPress core files, which is a no-go for me.

The third possibility, which is the one I went for, was to create our own meta widget. This is what the code below does.

Result: Our blog guidelines inserted into the meta widget.

I used the WordPress widgets API to create a widget, as well as the content of the standard meta widget, located in wp-includes/default-widgets.php. The code is located in our WMBlog plugin, a set of customizations specific to our blog that work independently of the theme.

The custom widget replicates the functionality of the standard meta widget (with the handy context-aware links) and also includes the link to our guidelines. It was a bit more work, but it’s cleaner and more robust that way. Once the widget is available, an admin can replace the standard widget with the custom one.

If you want to add stuff to the meta widget, or remove some of its standard content, this is probably the Right™ Way to do it. You’ll want to look at lines 42 to 51 in the code below.

Note: The code hasn’t been deployed to production yet; it’ll appear on the Wikimedia blog in a few days.

Code

/* =========================================================
   Replicate the default meta widget and extend it to include
   a link to the Wikimedia blog guidelines */

class WMBlog_meta_widget extends WP_Widget {

	function WMBlog_meta_widget() {
		// (constructor) Instantiate the parent object
		parent::WP_Widget( /* Base ID */'WMBlog_meta_widget', /* Name */'WMBlog_meta_widget', array( 'description' => 'The default meta widget plus Wikimedia-specific stuff' ) );
	}

	function form( $instance ) {
		// output the options form on admin
		// i.e. for now only the widget's title
		if ( $instance ) {
			$title = esc_attr( $instance[ 'title' ] );
		}
		else {
			$title = __( 'New title', 'text_domain' );
		}
		?>
		<p>
		<label for="<?php echo $this->get_field_id('title'); ?>"><?php _e('Title:'); ?></label>
		<input class="widefat" id="<?php echo $this->get_field_id('title'); ?>" name="<?php echo $this->get_field_name('title'); ?>" type="text" value="<?php echo $title; ?>" />
		</p>
		<?php
	}

	function update( $new_instance, $old_instance ) {
		// process widget options to be saved
		$instance = $old_instance;
		$instance['title'] = strip_tags($new_instance['title']);
		return $instance;
	}

	function widget( $args, $instance ) {
		// output the content of the widget
		extract( $args );
		$title = apply_filters( 'widget_title', $instance['title'] );
		echo $before_widget;
		if ( !empty( $title ) ) { echo $before_title . $title . $after_title; } ?>
			<ul>
			<?php wp_register(); ?>
			<li><?php wp_loginout(); ?></li>
			// Link to our own posting guidelines
			<li><a href="//meta.wikimedia.org/wiki/Wikimedia_Blog/Guidelines" title="General contribution guidelines for the Wikimedia blog">Blog guidelines</a></li>
			<li><a href="<?php bloginfo('rss2_url'); ?>" title="<?php echo esc_attr(__('Syndicate this site using RSS 2.0')); ?>"><?php _e('Entries <abbr title="Really Simple Syndication">RSS</abbr>'); ?></a></li>
			<li><a href="<?php bloginfo('comments_rss2_url'); ?>" title="<?php echo esc_attr(__('The latest comments to all posts in RSS')); ?>"><?php _e('Comments <abbr title="Really Simple Syndication">RSS</abbr>'); ?></a></li>
			<li><a href="http://wordpress.org/" title="<?php echo esc_attr(__('Powered by WordPress, state-of-the-art semantic personal publishing platform.')); ?>">WordPress.org</a></li>
			<?php wp_meta(); ?>
			</ul>
		<?php echo $after_widget;
	}

}

function WMBlog_register_widgets() {
	// register the plugin's available widgets
	register_widget( 'WMBlog_meta_widget' );
}

// plug in the widgets registration
add_action( 'widgets_init', 'WMBlog_register_widgets' );

User gallery example

I just found out by chance that a long-awaited feature for Wikimedia Commons had been enabled a few weeks ago. I’m talking about user galleries, i.e. the ability to list recent uploads by a user to a MediaWiki-powered wiki.

As if often happens, such a tool has been available on the toolserver for years (see an example), and a link to this tool was added to the default Commons interface for user pages.

Nonetheless, a “user gallery” feature built in MediaWiki, similar to the list of one’s edits, was still missing. We touched the subject during the Multimedia usability project, but we had to focus on the uploader.

A feature request was opened in our bug tracker back in 2005. This morning, while reading my bugmail, I saw a notification about this bug, saying the feature had been added in 2010 and deployed recently.

It turns out it was added by Bryan Tong Minh, a MediaWiki developer particularly active in multimedia features; he’s also the one who wrote the GlobalUsage extension a few years ago, which provides a list of all the pages around Wikimedia sites where a file is included.

It was already possible, in MediaWiki, to list files (in reverse-chronological order) through the Special:ListFiles special page. Bryan added the ability to filter this list by user, effectively creating a user gallery (r65013). He then added thumbnails to the page (r75582). The feature was enabled on Wikimedia sites (including Commons) as part of the deployment of MediaWiki 1.17.

So, it is now possible to see the gallery of uploads by a certain user (see an example). Want to see your gallery? Go to Special:MyUploads. Neat, heh?

The gallery is also accessible through the small “uploads” link at the top of your contributions list.

This feature is a huge step forward in terms of usability. During our interviews & testing, most people were wondering where their uploads had gone once the upload was completed. I’d like to thank Bryan, and all our awesome volunteers, for their work in making MediaWiki better.

The next step will probably be to add a shortcut to the gallery in the user’s top-right menu, as well as in the “Toolbox” menu in the sidebar. Maybe not on all wikis, but it would definitely be useful on Commons.

Further improvement could include the prettification of the page, perhaps à la Flickr, and the possibility to get the code to insert the image in a wiki page, as we do at the last step of the Upload wizard.

Actually, once that is done, we could pretty much replace the last step of the upload wizard by the gallery page, only with a thank-you message at the top. What do you think?

Boats on the Motława river seen from Most Stągiewny

It’s been a few months since Wikimania 2010 in Gdańsk. I had a few notes I wanted to share, but I was waiting for the Wikimania videos, which were never delivered. I’ll just go ahead and publish my notes now.

I went to Wikimania with my staff hat on, mainly to present and discuss the Multimedia usability project. I briefly presented the results of our research, then went on to demo the Upload wizard and play videos from our UX study.

The supporting slides are available on Wikimedia Commons; you can also download the PDF directly (2.36 MB).

I also submitted and coordinated a UX panel to provide a venue for users to ask their questions to the UX team. During this session, both the panel and the audience took notes collaboratively, which we found was a pretty effective means to maintain audience engagement!

The venue for the event was lovely; after WikiSym, hosted at the Music Academy in Gdańsk, having Wikimania in the Polish Baltic Philharmonic was awesome. Then again, I’m biased towards concert halls.

Program & Sessions

I wasn’t necessarily a big fan of the “Wikimania madness” concept at first: I personally hate to be rushed through something. But if you prepare your 30-second intro, the idea actually works quite well — provided everybody plays by the rules and speaks for only 30 seconds.

The overall program was awesome; with all due respect to the previous Wikimania conferences I attended, whose program was great too, I feel this year’s Wikimania was the best in terms of quality of talks. Huge props to the Program team!

The downside of it, obviously, was that it was extremely difficult to choose between concurrent sessions. For example, I missed the sessions about Talk pages and LiquidThreads, Semantic MediaWiki and Semantic Result Formats. I have some thoughts on how to solve this dilemma that I’ll publish later.

On Friday evening, we had the opportunity of attending a gala concert performed by the Gdańsk Baltic Philarmonic, directed by Felix Reolon. I’m hoping the recording will be made available, but in the meantime there’s an extract of the concert on YouTube. The concert was lovely, even though the audience didn’t necessarily measure up.

Many Wikimania sessions were better than the ones I attended at WikiSym. Harel’s talk about Conflicts between chapters and communities was both painfully accurate and delightfully funny. I feel a large part of the audience recognized themselves in both groups.

Another highlight was the presentation of the German mentoring program, by Tim Moritz Hector and his friends from the German-language Wikipedia. Their system seems to be fairly effective, and this talk was particularly relevant in a context where many criticize the unfriendliness of established editors towards inexperienced participants, but few act on it.

I was eager to watch the world premiere of Truth in Numbers, the documentary about Wikipedia, whose early cuts I had had the opportunity to see at Wikimania 2007 in Taipei. I ended up being quite disappointed, and the audience had mixed feelings about it overall.

Staff are people, too

The thing I like most about Wikimania is obviously the Wikimedians. Many of them interact a lot online, and sometimes become friends. Yet, most of them never get to see each other in person except once a year at Wikimania. This gives the event a rare intensity that I was looking forward to.

Unfortunately, I didn’t have too many opportunities to catch up with Wikimedians I know, or to meet new ones. When I talked to some of my Wikimedian friends online afterwards, they told me they had been reluctant to “using my time” for “just socializing” because it had become “more precious”  since I was an employee, and not “just” a volunteer.

While it was very nice of them to have that concern, I was still a tad disappointed. Wikimania is about meeting people, socializing and catching up with friends, more than attending presentations. Employees are not different than volunteers in that regard, especially when they’ve been long-time Wikimedians.

In a nutshell: Don’t hesitate to hang out with me (and other employees) at Wikimania next year!

Extract from the licensing tutorial. All graphics CC-by-sa, Wikimedia Foundation.

A few days ago, I announced the publication of the English version of an illustrated licensing tutorial for Wikimedia Commons. The tutorial was developed as part of the Multimedia usability project I’ve been working on for the past year. This article invites you on a behind-the-scenes tour of the licensing tutorial project.

Context

Because all Wikimedia projects are based on free licenses, Wikimedians have developed a particular expertise in this field, and in copyright in general. One of my favorite quotes about Wikimedians is from Sue Gardner’s keynote session at Wikimania 2009 in Buenos Aires:

You all know more about copyright law than any sane, sensible human being.

We do. And it’s hard to remember how little we knew about copyright a few years ago, when we had just started to edit. Back then, most of us had never heard about the GFDL, or about Creative Commons. Back then, we had never heard of Bridgeman Art Library v. Corel Corp. or the Place des Terreaux case¹.

Copyright is an incredibly complicated topic, especially in an international context. We’ve grown accustomed to it, but the learning curve is very steep for new users.

Copyright and free licenses are a complicated topic, and confuse many new participants.

Wikimedians generally like to be thorough, but we can’t expect new participants to read dozens of documentation pages before uploading a picture². We needed to create a high-level introduction that presented the basics without misrepresenting the complexity of copyright. No jargon, no legal precedents, no country-specific idiosyncrasies. There would be no “freedom of panorama” or “threshold of originality” here.

During the early stages of the licensing tutorial project, we even decided to ban the words “copyright” and “free licenses” altogether: they’re misunderstood and misinterpreted so often that we chose to explain these concepts in plain English, using practical examples. It was also consistent with our wish to provide plain-English descriptions of licenses in the upload wizard.

I started with a purposely short list of main points that we wanted to cover in the tutorial, and asked experienced participants to review them. The list was effectively a summary based on my own experience and a review of the existing instructions and documentation available on Commons. Then, we met with our illustrator to discuss the general approach and to agree on the rough content.

A collaborative effort

Finding an illustrator wasn’t an easy task. We had several non-negotiable requirements, listed in our Call for proposals. For example, we needed to find an artist willing to release their final artwork under a free license. We also had time and budget constraints.

With the help of Jay Walsh (our Head of Communications), we were able to find a talented illustrator who aligned with our values and met our requirements: Michael Bartalos, an illustrator from San Francisco, who had notably done some pretty awesome work for the California Academy of Sciences.

Puzzly is a character developed by Michael Bartalos in collaboration with experienced Wikimedians.

Michael was extremely accommodating with our hands-on, iterative and open process. Wikimedians are used to completely open, very inclusive processes, but it isn’t as natural in other fields, particularly in art-related disciplines. In the world of illustration, in particular, you usually try to keep all your preliminary and in-progress artwork secret to prevent other people from stealing your still-rough ideas.

Luckily, Michael and I were able to find a middle ground. We agreed not to publish the in-progress designs, and he agreed to let us share them privately with members of our community interested in providing feedback.

I explained the context and reasons honestly on the Commons mailing list and Village pump, and the participants were very sympathetic to these constraints. I invited people to sign up if they were interested in providing feedback, so they could receive a link to the artwork. Most of the people who signed up did write useful comments, and all of them respected our request not to republish it. The feedback they provided was very constructive and of high quality.

We went through this process a few times, first to comment on the general approach and content, then to focus on specific details of wording and graphics.

I found that it helped immensely to ask specific questions to commenters. I structured the page into specific sections and most commenters naturally added their feedback in the appropriate place. I initiated the sections with my own comments, in order to save other people’s time.

Some comments were similar, while others were in disagreement. The preparation made it easier to provide the illustrator with a consolidated summary to help him work on the next version without having to deal with long discussions and contradictory statements.

Translation and localization

The tutorial has been translated and localized into many languages, such as Arabic.

Once the English version was ready, the translation process started. Casey Brown and I prepared the translation framework and provided detailed pieces of advice, in order to inform translators and help them with this particular translation request.

I used to be a Wikimedia translator myself, and I knew how effective they were. Still, I was amazed to discover that, after only three days, about 20 translations of the text had been completed. Furthermore, they had already integrated the translations in about a dozen localized versions of the artwork.

As it turns out, the coordination page containing advice and instructions proved to be very helpful to translators, and well worth the time I had invested in it. About eighteen localized versions are available now, and more are underway.

What next?

The real test, of course, will be when new participants are presented with the tutorial. Will they like it? Will they read it, or jump directly to the next step? Will the tutorial be successful in helping them learn what we want to teach?

So far, we haven’t formally tested it. We were hoping to conduct a study on the tutorial and the latest version of our upload wizard prototype, but we had to postpone it. I do hope we’ll be able to measure the impact of the tutorial at a later point. Still, the enthusiasm with which the tutorial has been welcomed is, it seems, a good sign.

I hope this summary will be helpful to people conducting similar projects. I feel the interaction with the rest of the community has been quite smooth during the whole project. It would be presumptuous to think it was only because I’ve been a long-time community member myself, but it sure helped to speak the same language as the users’.

More generally, the Multimedia usability project was the first engineering project of the Wikimedia Foundation with a Product Manager on its team. I feel this role has played a critical bridging role between the users and the rest of the team, to everyone’s benefit. I’d love to see this happening more regularly in WMF-driven projects.

My own lessons learned, in a nutshell:

• Trust the Power of The Crowd.
• Collaboration is worth the effort.

Notes

Gate of Great Centrality and Perfect Uprightness and Democrary Memorial Hall in Taipei, Taiwan

Our volunteers are awesome. More specifically, Magnus Manske is awesome. He just made reusing pictures from Wikimedia Commons a hundred times easier.

The story begins in October 2009.

About a year ago, I created some mock-ups of what the ideal file description page should look like on Commons. One of my suggestions was to add a series of buttons for one-click reuse cases, to make it easier for people to reuse the more than 7 million files available on Wikimedia Commons.

One-click reuse cases from the October 2009 draft mock-ups

These prominent buttons would help users embed the media files in wiki pages, HTML code or simply download the file. If you wanted to include the file in a Wikipedia article, it would provide you with the wikicode for it, so you would only have to copy/paste the code snippet, without having to be a wiki expert. Same thing if you wanted to include the file in an external web page. The “Download” button was an attempt to make the current (and quite frankly, hidden) download link more obvious.

Code snippets from the October 2009 mock-ups

Magnus Manke’s “Stock photo” tool

Last week, Magnus Manske created a small JavaScript piece of code to add a “Stock photo” feature and mentioned it on the Commons mailing list. Magnus is one of the original developers of MediaWiki, but nowadays he mostly works on Toolserver and JavaScript tools, especially for Commons.

The tool he wrote was pretty neat, and User:TheDJ and I briefly talked about it on IRC. I also pointed TheDJ to my earlier mock-ups from last year, explaining how the idea was similar.

Today, as I was visiting Commons, I was stunned to see a new version of Magnus’ tool, available on all file description pages, that was clearly inspired by my design. You can see for yourself by visiting any file description page on Commons.

Screenshot of the buttons as now implemented on Wikimedia Commons

Apparently, TheDJ pointed to my design in the discussion on the Village pump, Magnus implemented it and the feature was globally enabled on Commons for all users.

I think this is fantastic.

Magnus not only reused my design, but he even made it better by adding the possibility to select the size of the file you want to download or embed.

As we held the user experience study for the prototype upload wizard, our users were really pleased to see similar code snippets at the last stage of the wizard, but they were wondering how to obtain this information again. Until now, they couldn’t. Now, anyone can.

We couldn’t implement the improved file description pages as part of the Multimedia Usability grant, because we had to focus on the new upload system. I’m really thrilled to see volunteers taking on such tasks, and I’d like to express my deepest gratitude and thanks to Magnus, TheDJ, and more generally all the awesome volunteers who help make our software platform better.

The tool’s code is available at MediaWiki:Stockphoto.js; comments and bug reports can be left on the talk page.

In a nutshell, reusing media files from Wikimedia Commons just got a lot easier; this is really nifty. I imagine it would be great if this feature, along with a few similar others, could be integrated directly into MediaWiki, or into an extension for media repositories to be enabled on Wikimedia Commons.

The Tower of Babel, by Pieter Bruegel the Elder

This article is a follow-up to my previous article about the state of the language selection in MediaWiki and Wikipedia.

Have you ever had a hard time finding your language in a web interface? The interface of MediaWiki is available in literally hundreds of languages, where many other major websites only care about English, and maybe a handful of other “major” languages.

The problem is that, with the number of available languages growing, it has become difficult to find the one you’re looking for. Especially if you don’t know in what language it’s displayed, or how the languages are ordered.

The Universal language picker aims to solve this problem by accepting any valid input from the user and associating it with the language value stored in the software.

Context

The main focus of the Multimedia usability project right now is on developing a new upload wizard, to replace the insanely complicated current upload form on Wikimedia Commons. It’s not going as fast as I expected, but we’ve made some great progress recently.

A few months ago, we did some “hallway testing”: we asked some of our co-workers (who aren’t necessarily wiki-experts) to try out the upload wizard. As they were using it, we watched them and tried to identify what was confusing, in order to improve the interface & interaction with the user.

It was really interesting, as they were all using the upload wizard differently. One was an “explorer”, who would expand each and every sub-menu in order to better understand the options offered to her. Another would just try to proceed as fast as possible, get the job done and get it over with. It was a sort of rehearsal for our then-upcoming User experience (UX) study, and we learned a lot.

Where’s my Hindi?

Drop-down language selector currently used in the JavaScript-enhanced upload form on Wikimedia Commons

During the testing, one of our victims was Aradhana Datta Ravindra, the Project Manager for the Bookshelf project. Aradhana was born and raised in India, and Hindi is her mother tongue.

Our prototype makes it possible to add descriptions in multiple languages. After uploading her picture, Aradhana added a description in English, then naturally tried to add one in Hindi. The problem is, she couldn’t find Hindi in the list.

The interface we use to select the language of each description is a basic drop-down menu, similar to the one already available on the current upload form.

On Commons, the list is ordered by ISO 639-1 code (sort of) but displays the name of the language in this language. For instance, Chinese is displayed as 中文 but listed at the end of the list, because its language code is ‘zh’. You have no way of knowing how languages are sorted.

In our case, the list was ordered slightly differently. It would show the same thing, but ordered as the characters appear in the UTF-8 tables. However, the problem was similar in both cases: the user couldn’t know how to find their language in the list.

We’re not talking about a 10-item-long list. We’re talking hundreds of languages (356 at the time of writing). So, if you don’t know where to look, it can take a while to browse the whole list.

When Aradhana started to look for Hindi, she realized the list was very long. She tried to type ‘h’ to jump to “Hindi” directly. Except Hindi wasn’t there. It was at the bottom of the list, with other non-latin scripts.

Non-latin languages at the bottom of the list in the language picker on Commons Prototype

Later, we had a very interesting discussion about how we should show languages in the drop-down language selector.

Language displayed in the same language

One viewpoint is that, if you’re looking for a language in the list, you should know the name of this language in this language. For example, if you’re English, but you’re looking for German, you should know that the German name for “German” is “Deutsch”.

This is currently how MediaWiki handles language selection in most cases, because this system is considered to be the most language-neutral (see my previous article on this topic). The language picker in your Wikipedia (or other MediaWik-based wiki) user preferences is an example if this:

Drop-down menu from MediaWiki's user preferences to select the language of the interface

Also, although languages are usually displayed in their own language, they’re sorted by ISO code (as in the example above). On the one hand, it makes it easier to jump to your language (if you happen to know the ISO code for it, and your keyboard can input latin characters). On the other hand, the displayed names and the sorting order are inconsistent.

Language displayed in the user’s language: The n × n issue

Another viewpoint is that all languages should be presented in the user’s language. If we consider the same example (you’re English and looking for German), the software should present you with a full list of languages with their English name, and you would be able to select “German”.

That would basically require us to know the name of all languages in all languages. For n languages, you would need a total of n × n translations. That’s a lot.

Illustration of the language table for 3 languages and its extension to an arbitrary number of languages

Even then, the table is obviously incomplete, and may stay incomplete forever. Do you know how to say “French” in Cherokee? I don’t. Wikipedia doesn’t, either (yet).

#include <mindreading>

An n × n language table will be missing many translations.

Actually, even if we somehow managed to get a complete table, we’d still have a problem. Let’s assume for a second we’re able to know the name of every language on the planet in every other language. Some estimate the number of current languages up to ca. 7,000. That means we would have a complete table of 7,000 × 7,000 languages, i.e. ca. 49 million entries.

Now, how do we sort them?

The fact is, you can never really know what the user is going to input. How do you know if they’re entering the ISO code, the name in English, the name in German, etc.? What if the user happens to know and regularly use the ISO 639 code, but doesn’t know the name of the language¹? For extremely long lists, we can’t expect the user to go through the whole list if they don’t even know how it’s ordered.

It all boils down to the implementation model vs. the user model. But in this case, there are multiple users models.

Comes the Universal language picker

The main problem with the previously presented approaches is that they all assume a bijection between the displayed name and the value in the software, i.e. a one-to-one correspondence. Whether it’s displayed with the ISO code, the name in English, or whatever, there’s always only one representation possible for each language.

In the end, what we need is a way to assign multiple representations to a single language value in the software. We need a surjection that recognizes every possible input from the user and associates it with the language value stored in the software.

Surjection between all the possible inputs from the user, and the language value stored in the software

Now, what kind of interface can we use to implement this model?

A simple input field with autocomplete.

Simple as that. Forget endless drop-down menus with weird sorting orders. All we need is a simple input field with autocomplete containing all existing items in the n × n languages table. It doesn’t matter if it’s incomplete: as we get more translations, we’ll add them to the table.

Of course, we’ll need to use an arbitrary sorting order for autocomplete suggestions anyway. But by using an input field with autocomplete instead of a drop-down, the user can refine their search and dramatically decrease the size of the subset of items they’re searching in.

Ideally, the user wouldn’t even have to search: in many cases, it’s possible to guess a sensible default language, based for example on the browser language. We could pre-populate the input field with a grayed out default text that disappears if the user clicks to edit the field.

Further implications

This design has broader applications: the upload wizard is not the only place where the user might want to select a language. User preferences are an obvious example.

Given the multilingual nature of Commons, it would even make sense to add a language selector for the interface on the sign-up page. Right now, the user has to go change the language in their preferences after they’ve signed up.

I’d be delighted to hear opinions and comments about this proposed design. Do you think it would work? How technically feasible would it be?

Notes

The WikiSym 2010 banner, designed by yours truly (except for the logo, by David Bailey).

WikiSym & Wikimania in Gdańsk

I couldn’t attend WikiSym the previous years for various reasons, the main one being money: they were too far away and the registration fee was too expensive. This year, WikiSym was collocated with Wikimania in Gdańsk, Poland, so it was a perfect opportunity for researchers & Wikimedians (or “practitioners”, as researchers call them) to get together and meet. We have to thank my friend Phoebe Ayers for that, who was this year’s Chair/Organizer of WikiSym.

I was pretty excited because WikiSym seemed to be at the crossroads of two of my circles: academia & open collaboration. I was also really looking forward to meeting researchers: the Wikimedia Foundation is currently engaged in an effort to include research into their decision-making process in order to make it more data-driven. Thus, it was the perfect time to try and build awareness, understanding and relationships between the two communities.

Open space schedule boards at WikiSym 2010

Program & Sessions

The symposium was a mix of regular conference talks and an unconference-style Open space track. I wasn’t necessarily a big fan of the unconference style, but one of the most productive discussions I had (about quality assessment tools) actually happened in a group I walked in a bit randomly. I was a bit disappointed by the quality of some talks, but overall the event was great.

One major issue, though, was the number of conflicting talks: there were up to eight concurrent open space sessions, conflicting with each other, as well as with the main sessions and workshops. It was just impossible to take part in everything one was interested in. While this is a usual problem with large events, I didn’t expect to have this issue in a relatively small conference like WikiSym.

I gave a presentation entitled Understanding the users of Wikimedia Commons, a summary of the user research I did for the Multimedia usability project, and it was pretty well received. The audience particularly liked the video I showed from our UX study. The supporting slides are available on Commons  (download the PDF – 504 KB). Unfortunately, the presentation wasn’t recorded, but it was similar to the one I gave at Wikimania, whose recording will be available soonish.

Me trying not to burst into song, being on stage in such a nice Concert hall (CC-by-sa by Blue Oxen Associates)

Not as open as you might think

The second day ended with a discussion in the “Open circle” about copyright. Specifically, the participants asked if they could publish their work (that they presented at WikiSym) under a free license. I was particularly interested, since I had had the very same discussion a few months before.

« Open circle » at WikiSym 2010

In March 2010, I submitted a scientific paper to WikiSym about my work. I had written papers for scientific journals & conferences before, but it was the first time I submitted one in this specific field of research. As a consequence, I was quite happy when my paper was accepted.

Then came the copyright transfer issue. WikiSym partnered with the ACM to publish the proceedings of the conference, and the ACM asked me to transfer my copyright to them. While this is fairly standard in the scientific publishing industry¹, I was surprised by this requirement considering the field of research involved (open collaboration and free knowledge).

I shared my concerns with Phoebe and with Felipe Ortega (Chair of the Program Committee), who reached out to the ACM. The ACM wouldn’t let me release my work under a free license such as Creative Commons Attribution Share Alike (CC-by-sa). I felt my research belonged to the Wikimedia community, and I didn’t want to enclose my work within the ACM’s intellectual property prison.

Hence, I refused to sign the copyright transfer form, even though it meant not being able to present my work at WikiSym. In the end, thanks to Phoebe & Felipe’s efforts and discussions with the WikiSym committee, I was allowed to present my work, but only as a lightning talk, and it wasn’t included into the conference proceedings.

I do hope, though, that at some point we’ll be able to move towards a more open access & reuse model², in accord with the philosophy of open collaboration and free works.

Notes

The observation room at the testing facility; the testing is happening in the background, behind the semi-transparent glass (CC-by-nc by Neil Kandalgaonkar).

Getting there

We reached out to some UX firms and published a Call for proposals in February. Several firms submitted proposals; after serious consideration, we chose to work with gotomedia, a San Francisco-based firm that seemed to align best with our goals & values.

The study was planned to take place in March, but was postponed because the prototype was not ready. In the meantime, we asked some of our co-workers to test it in order to uncover the most obvious flaws & bugs.

Goals & testing conditions

A few weeks ago, the actual testing eventually took place. We tested ten users: five locally in San Francisco, and five remotely within the US. We considered conducting similar testing abroad, in order to identify language-specific issues; but in the end, it turned out that we wouldn’t learn a lot by simply replicating the same test script.

Multilingualism on Commons (and Wikimedia websites generally) is a huge piece of work that deserves dedicated efforts, and dedicated UX studies. The main reason for which we decided to hold the testing halfway through the project, and not at its very beginning, was that we could test both the current upload interface, and our prototype.

On the one hand, during our preliminary research phase, we identified a large number of issues with the current interface; but we still needed to formally record the user experience and validate our preliminary conclusions. On the other hand, we wanted to do a reality-check with our prototype, to see if the direction we had chosen was appropriate, and to identify areas of improvement.

Highlight videos

The testing sessions went pretty smoothly. The gotomedia folks did a fantastic job at preparing the “highlight videos” in time for our conferences in Gdańsk (WikiSym & Wikimania). The audiences really liked them, although we didn’t have time to show all of them.

Highlight videos are edited summaries of the main findings of the study. In our case, we have three highlight videos: one about the testing of the current interface on Commons, one about the testing of the prototype, and the last one about how we could improve the prototype.

Long story short: the current interface is a nightmare, and the prototype is way better, even if there are some minor things to improve. The good news is, all the items to improve were already planned features at the time of testing, and they have either already been added, or will be before the upload wizard is released.

Namely, one of the main remaining issues is the fact that users don’t really understand copyright and free licenses. That’s why we’ve been working on a licensing tutorial at the same time, to be released jointly with the new upload wizard.

See for yourself

The highlight videos are now available on Wikimedia Commons; per our agreement with gotomedia, all the videos were released under the Creative Commons Attribution – Share alike 3.0 license.

In the tradition of Wikipedia’s Neutral point of view policy, we’ll try to upload the unedited videos to Commons as well, in order to let the community draw their own conclusions.

If you would like to draw our attention to things we’ve missed, or even edit your own highlight videos yourself, you are warmly invited to do so. You can watch the highlight videos below (if it works) or on Commons. The links to Commons are available below if you want to download the video files on your computer.

Your feedback and comments are much welcome.

Current interface highlight video

Prototype highlight video

Room for improvement highlight video

Files

• Current interface testing: File page on Commons – Download OGV file (4m11s, 29.89 MB)
• Prototype testing: File page on Commons – Download OGV file (5m32s, 35.43 MB)
• Room for improvement: File page on Commons – Download OGV file (3m51s, 23.02 MB)

and it was fun.

Shared values & challenges

It might seem odd for Wikimedia to be presenting at KDE Akademy: Wikimedia is mostly about online content, while KDE is mostly about desktop software. Yet, they share common goals & values.

On the one hand, a common criticism made against KDE is its feature creep: the tendency to allow for maximum customizability in KDE often comes at the price of simplicity and ease of use.

On the other hand, MediaWiki, the software on which rely Wikipedia and the other Wikimedia websites, suffers from the same flaws: it has always been “designed” by developers. As a consequence, the interface reflects the implementation model, and often doesn’t match, or even conflicts with, the user’s mental model. The Wikimedia Foundation recently started to include user research and design as part of their development cycle, where user experience is taking a increasingly critical role.

Our presentation at Akademy was an opportunity to share experience. Both KDE and Wikimedia communities struggle to improve complex interfaces, and both communities have a lot to learn from each other.

Wikimedia and KDE also have more practical ties: Wikimedia Deutschland e.V. and KDE e.V. used to share an office a few years ago. I’ll take this opportunity to thank Claudia Rauch for inviting us to submit a proposal for Akademy this year.

Presentation slides & video

Thanks to KDE e.V. and their awesome volunteers, the full video of our talk (and the follow-up discussion) is available, along with all the other videos, from the Akademy schedule page. A slightly edited version is also available from Wikimedia Commons; you can also download the file to your computer (Download – OGV, 162 MB). Or, you can watch it below, if it works.

The presentation slides aren’t very useful alone, but they’re also available on Commons if you want to take a look or watch them alongside the video (Download – PDF, 2.2 MB).

Meeting the KDE community

I’ve had some interaction with the KDE community before. I used to live in the same city as one of the lead KDE developers, and we belonged to the same LUG. I’m also familiar with the digiKam community, with whom I’ve been working on and off.

Besides our presentation, Akademy was also an opportunity to get together with the “gearheads”, to discuss collaboration opportunities, and of course to get my debugging duck.

« Take the duck from your desk, look at your code and explain to the duck - line by line - what it does. »

Working hand in hand

We had planned to hold a more hands-on workshop to discuss practical common projects between the two KDE & Wikimedia communities. Unfortunately, I had to leave Tampere early to fly to Gdańsk for WikiSym & Wikimania. I didn’t have much time to explore the city either, which is a pity; Tampere is a quaint little city, and the surroundings looked really charming.

I would still like to work on common projects, as I think there’s a huge potential for a better integration of Wikimedia websites with the desktop. Since I’ve been thinking about this for a while, I have a few ideas of my own: mass upload tool, offline wiki editor, desktop widgets (e.g. for Wiktionary, FAOTD, POTD), application plugins (e.g. to find media files from Commons from within an application), instant messaging with other Wikimedia editors, etc. That said, I would also like to collect ideas & feedback.

So, what Wikimedia content would you like to access from your desktop? For what use? What desktop tool would facilitate your editing or reading of Wikimedia projects?

There are two main use cases for language selection across Wikimedia projects: the language of the content, and the language of the interface. In this article, I am reviewing a few examples of tools related to language selection on MediaWiki websites, and particularly on Wikimedia wikis.

Interface language selection

Language setting in user preferences

On each MediaWiki website, users who create an account can select the language of the software interface. That means, for example, that you can read Wikipedia articles in Italian, but with the interface in French. This feature is particularly useful for Wikipedia participants who are familiar with the interface in their mother tongue.

Drop-down menu from MediaWiki's user preferences to select the language of the interface

The default language for MediaWiki messages is English. The localization of MediaWiki has been made possible with the translatewiki.net platform (former “betawiki”) and the hundreds of volunteer translators who try to keep up with the ever changing MediaWiki messages. And they’re doing a terrific job.

This language setting, though, only works for registered users. If you’re only a reader and you don’t have a user account, you’re stuck with the default language specified for the website. Usually, the default interface language is the same as the content language, and most readers are content with that.

The problem comes with multilingual wikis, i.e. wikis that contain content in several languages. For example, Wikimedia Commons, Wikimedia meta-wiki and the Wikimedia Foundation website are multilingual wikis; they are central places for Wikimedians from all projects in all languages.  Only one interface language can be used as the default, and it’s generally English. If you can’t read English and you’re looking for media files on Wikimedia Commons, you’re going to have a hard time navigating the site.

The uselang parameter

A workaround is to use the uselang parameter to specifically ask MediaWiki to render the interface in a given language¹. An example of its use is the “Commons” template, used on some Wikimedia projects to provide a visible link to the Commons page or category about a specific topic. If you’re reading the Catalonia article on the German-language Wikipedia, and scroll to the bottom, you’ll find a link to Commons directing you to the Catalonia category on Commons, but with the interface in German.

This method has obvious drawbacks: first, you need to actually know it exists, and how to use it. You also need to know the ISO 639 code of the language, but if you know the uselang parameter exists, I’ll assume you know that language code as well.

More importantly, the uselang parameter isn’t persistent, i.e. it will go away as soon as you leave the page you were viewing. There’s an open bug to preserve the uselang parameter during sessions (bug 4125). But for now, if you land on a page rendered in a specific language using uselang, it’ll revert to the default language as soon as you move away from that page.

LanguageSelector extension for MediaWiki

Going a bit further, Daniel Kinzler developed an extension for MediaWiki called LanguageSelector. The first feature it provides is to automatically detect the browser language² of unregistered readers and defaults the interface to their language.

Such an automatic system would be desirable for some Wikimedia websites, especially Commons, but it requires scalability improvements: it would fragment the cache, on which we rely heavily for performance. Nonetheless, it’s an issue that’ll have to be addressed in any case.

The LanguageSelector extension also provides a drop-down selector that can be included in pages. This setting seems to follow the user at least during the session. You can see an example of it used on the home page of translatewiki.net.

Drop-down language selector from the LanguageSelector MediaWiki extension

Content language selection on monolingual wikis

Wikipedia.org portal

Wikipedia and most other Wikimedia websites are available in many different languages — over 250 at the time of writing. And that’s just existing Wikipedia editions; several thousand languages are spoken across the world population.

On monolingual wikis (i.e. wikis whose content is in only one language), there are two occasions where you may want to select a language: the first is when you choose what site you want to visit, e.g. Wikipedia in English or Wikipedia in Spanish. The second occasion is when you want to navigate from one language edition to another, e.g. from Wikipedia in English to Wikipedia in Spanish.

On Wikipedia, the first choice happens on the multilingual wikipedia.org portal, if you ever happen to go there.

Screenshot of the Wikipedia.org portal

On this (manually curated) portal, each language is displayed in the language’s language³: English is displayed as “English”, German as “Deutsch”, French as “Français”, etc. The sorting order is based on the size of each language edition, measured in number of articles. In a word, the bigger the Wikipedia, the more prominent the place. “Small” Wikipedia editions are at the very end of the list.

In most cases, though, you don’t have to make this choice; your search engine conveniently directs you to the language edition of Wikipedia in your language. Once you are on a specific language edition of Wikipedia, though, you can still navigate to related articles in other languages, using interlanguage links.

Interlanguage links

Interlanguage links are a specific subset of interwiki links; they allow users to navigate between different language versions of the same page.

Links and their order are curated by humans or “bots”, i.e. external programs that interact with the software as humans would, but are not part of the MediaWiki software

List of interlanguage links of the Apple article on Wikipedia in English, and the wikitext that generates them

The sorting order differs from a Wikipedia to another; they have different standards. That means interlanguage links will be sorted in a different order, whether you’re reading an article on the Polish Wikipedia, the Finnish Wikipedia, or the Serbian Wikipedia. Convenient, eh?

The default behavior for interlanguage links is to display all the available links. For the most common topics, the list can grow quite long. The main page, for example, is the page all language editions are sure to have in common. The interlanguage list for the main page is usually truncated by Javascript in order to avoid having 250 links there.

List of interlanguage links displayed on the main page of Wikipedia in English

Content language selection on multilingual wikis

Multilingual wikis

Wikipedia editions exist in only one language at a time. It’s the same for most of the Wikimedia websites, like Wikisource or Wikibooks. Some projects, though, are meant to be a central place for all Wikimedians.

For example, Wikimedia Commons (“Commons”) is the central media repository for all Wikimedia projects. Rather than duplicating media files on all of them, they’re centralized into one media library.

Wikimedia meta-wiki (“meta”) is another multilingual wiki. Its purpose is to serve as a central coordination platform for the Wikimedia community.

Both these wikis are “multilingual”: they host content in a variety of languages. But MediaWiki wasn’t originally designed for such a use; it was designed to host content in only one language. The community has had to work around this limitation by implementing various tricks & hacks.

JavaScript language select tool

For a few years, meta has been experimenting with the Language select tool. Language select is a JavaScript hack⁴ that basically hides the text that isn’t in the language you’ve selected.

There too, you have to know the ISO language code, and the user interface isn’t very intuitive, but it was a start. The newer JavaScript method detects the language of your browser automatically.

Screenshot of the language select JavaScript tool on meta-wiki

A similar system is also available on Commons, through the Multilingual description template. As far as I know, though, this template is very rarely used; instead, individual language templates are the standard way of labeling (and sometimes, choosing) content in different languages.

Language templates

Language templates are used to specify the language of a specific part of a content’s page, for example descriptions of a picture on Commons. They also allow registered users to hide content they don’t understand, by specifying a “blacklist” of languages they don’t want to display. It’s particularly useful for Featured pictures, or Pictures of the Day, that contain many translations for the caption.

Description of a Picture of the Day on Commons in various languages

Langswitch & Autotranslation

Langswitch and Autotranslate are two similar methods used on Commons to show a given text depending on the user’s language (as specified in their preferences). They’re more elaborate systems than Language select and Language templates, but they essentially try to address the same issue.

Langswitch is more lightweight and used for simple templates: all translations are contained in one page. For example, the “France” template on Commons uses Langswitch; it includes the translation of the word “France” in all available languages, and provides a link to the appropriate article in the associated language edition of Wikipedia. If the user’s language is German, they will only see “Frankreich“.

Autotranslate is used for heavier templates that contain more text; in this case, it is easier to segregate the translations into dedicated subpages. This is how license templates have worked (although they’re now being replaced, see below).

A template using Autotranslate (called “autotranslated template”) typically consists of a subpage defining the template’s layout, and a subpage for each translation of the template’s messages. The “PD-self” template is autotranslated, for example; it has a layout subpage, and subpages for all available languages, such as English, Japanese and Russian.

The {{int:}} MediaWiki “magic word”

{{int:}} is a MediaWiki magic word used to show a MediaWiki interface message in the user’s language (as set in their preferences). Its main limitation is that it only works for MediaWiki interface messages. Yet, I am placing it into the “Content language selection” section, because it has recently been used to replace Langswitch and Autotranslation.

Using {{int:}} to display something in the user’s language is a more robust system; it’s also the reason for which license templates were converted to system messages (and bundled into the WikimediaLicenseTexts extension).

Basically, in the case of Commons, many templates requiring translation rarely change (e.g., the licensing templates). As templates, they belong to the content, not the interface. But licenses are managed with templates because the software doesn’t provide a built-in interface for them. Ideally, licenses would be managed by MediaWiki itself (or an extension). But we’re not there yet.

So, what’s currently happening is, these licensing templates are being replaced by alternatives that use custom MediaWiki messages. The content that was once stored in the templates is being moved to dedicated interface messages. That way, they can be automatically displayed in the user’s language using {{int:}}. And they can also be translated by the translatewiki.net community.

This system doesn’t solve the issue for unregistered users, though.

Conclusion

There is a multitude of cases where a user may want or come to select a language while navigating a Wikimedia site. They may want to choose in what language the website interface will be displayed, or select the language of the content.

For multilingual Wikimedia wikis like Commons and meta, language selection is a regular issue, because they intrinsically target a multilingual audience. Some ad-hoc systems have been developed over time to try and work around the technical limitations of MediaWiki, but they can’t replace a built-in language management system.

Current language selection solutions also don’t cater for the needs or unregistered readers, who are the majority of the people visiting Wikimedia projects. That issue will have to be addressed at some point if we want to reach a truly global audience.

Another challenge with language selection is the interface you provide the user with to make their choice, i.e. the actual “selector”. It is not obvious what design is the best and allows the user to select the language they want in the most efficient manner. This will be the topic of my next article.

Notes