Skip to main content

State of the language selection in MediaWiki and Wikipedia

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 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.[1] 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[2] 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

Drop-down menu showing a list of languages in their language, prefixed by the language code

Drop-down language selector from the LanguageSelector MediaWiki extension

Content language selection on monolingual wikis 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 portal, if you ever happen to go there.

Screenshot of the portal; The Wikipedia logo is surrounded by the 10 largest language editions, then languages are listed in size groups

Screenshot of the portal

On this (manually curated) portal, each language is displayed in the language’s language:[3] 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.

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[4] 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.

Cropped screenshot of a web page showing a small input field with the text 'en' in it, followed by two buttons, saying 'Select' and 'Show'

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.

Descriptions in German, English, French and Italian; the language is formatted in bold font.

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 community.

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


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, about language selectors.

Temporal evolution of the content & participants of Wikimedia Commons

As part of the Multimedia Usability project, I have been doing a lot of research to better understand how Wikimedia Commons is functioning, and particularly to understand its users & participants. One side I am particularly interested in is the demographics and the content dynamics of Commons.

In June last year, I summarized my view with the following comment:

The main issue of Commons is that it is growing way too fast. This issue is quite unique in Wikimedia projects: when a wiki is growing, it is usually growing because its community is growing. The issue with Commons is that it is a central repository used by almost all the other wikis; many users on Commons are not regular participants there, they only use it to upload pictures for their wiki and they don’t involve themselves in the local Commons community, which remains limited. As a consequence, this Commons community doesn’t have the human resources to face the workload induced by the growth of the wiki.

In a nutshell, Commons’ issue is that the wiki is growing faster than its community.

Yet, this statement was only an opinion, and was not based on actual research. My opinion hasn’t changed much since then, but now I actually have some data to support this hypothesis.

Content and community growth

There has been much interest in the academic world about “Who writes Wikipedia?” and whether most of the content is contributed by an elite group of participants or by occasional visitors.[1][2] Roth et al. studied the factors influencing wiki viability and noted a “dynamical intertwinement of population and content growth;”[3] they had earlier suggested that a wiki’s success was linked to “a virtuous demographic path with content and contributors co-evolving.”[4]

In a media repository like Wikimedia Commons, however, the focus of activity is on contributing new media files, rather than improving the existing ones. Once a file has been uploaded, improvements are mostly limited to metadata and peripheral information (description of the media file, copyright information, general topics, location, etc.); the files themselves are rarely edited. As a consequence, it is particularly interesting to study the dynamics of population & content in this special case. For this purpose, I studied the temporal evolution of the Files-to-active Participants ratio (F:P) and compared it to the Articles-to-active Participants (A:P) ratio on the English Wikipedia (Fig. 1, below). All the data come from


Fig. 1: Temporal evolution of the ratio of media files on Wikimedia Commons per active participant (orange squares) and evolution of the ratio of articles on the English-language Wikipedia per active participant (blue triangles).

While the articles-to-participants ratio has remained stable on Wikipedia after the first few years of existence, the files-to-participants ratio has been steadily increasing since the creation of Wikimedia Commons. F:P has exceeded A:P since then and is now ten times higher than A:P. This demonstrates that Wikimedia Commons, despite being successful in terms of content, does not follow the usual model of “viable” or “successful” wikis, and requires new metrics and new models.

Content inflow management

Because of the fundamental difference between a text-based encyclopedia and a media repository, a more interesting approach is to compare the capacity of the community of participants to “absorb” the inflow of new content contributed to the platform. Thus, I studied the temporal evolution of the ratio of persistent new media files uploaded each month, per very active participants on Wikimedia Commons (Fig. 2).

I compared it to the ratio of persistent new articles per very active participants on the English-language Wikipedia. “Persistent” means that I only counted media files and articles that were not deleted during the patrolling process; the actual number of files uploaded and articles created is higher. I chose to consider only very active participants (more than 100 edits per month) since they are the more likely participants to engage into patrolling activities, such as checking newly uploaded files or newly created pages.


Fig. 2: Temporal evolution of the ratio of persistent new media files on Wikimedia Commons per very active participant (orange squares) and evolution of the ratio of persistent new articles on the English-language Wikipedia per very active participant (blue triangles).

The ratio of persistent new media files per very active participants has doubled since the creation of Wikimedia Commons and still continues to increase. This ratio is now more than ten times higher than the one for articles on the English-language Wikipedia. Because of this imbalance between the growth of the content and the growth of the community, Wikimedia Commons faces a peculiar challenge.

Using appropriate tools

Some may argue that comparing uploads and the creation of new pages is like comparing apples and oranges; I agree to some extent. For this reason, I have also studied the evolution of the number of edits on the English Wikipedia, which may be a better indicator of the inflow the community has to absorb. This will be the subject of an upcoming article.

The MediaWiki software provides various maintenance and patrolling tools that allow participants to check newly contributed content; one of these tools is the “watchlist”, a personal page listing the recent changes made to pages of interest selected by each participant. Watchlists are appropriate for text-based wikis like Wikipedia where participants want to check new edits to existing pages, rather than new pages.

However, maintenance activities on Wikimedia Commons mainly consist of checking new files (especially their copyright status) and classifying them appropriately. For this purpose, the usefulness of the watchlist is limited. Some ad-hoc tools have been developed by power participants, but MediaWiki does not provide dedicated features to help the limited community of participants absorb the inflow of new media files. This is where the Multimedia Usability project can step in.

Scaling up Software development for Wikimedia websites

I have previously explained why the current setup of the Wikimedia bug tracker is not ideal. I have also advocated for a more managed & scientific software development strategy. This article aims to discuss an appropriate tool to support this strategy, and at the same time fix what is broken.


Tooled Flatty by flattop341, under CC-By, from Wikimedia Commons.

Software lifecycle & Project management

Right now, there is little project management of the technical activities at the Foundation. When someone does manage projects, they often use personal desktop applications that don’t allow collaborative work. There isn’t any real development roadmap or product requirements. If we want to be serious about structuring our activities, we need a project management strategy & the appropriate associated tools that allow us to manage things such as project scope, schedule, budget & financial resources, quality assurance, human resources, communications, risks & opportunities, procurement and coordination.

I asked around to see what the needs of the various members of the team were. Naoko Komura, who has been project-managing the Wikipedia Usability Initiative, and is now overseeing all UX programs, is particularly interested in the integration of the Project management platform with calendars & issue tracking. Operations staff members also said they were interested in Project management features such as time and task tracking.

I think it is way past time to have a more organized development process & software lifecycle management. The recent hiring of a new Chief Technical Officer is a step towards a more structured organization of technological activities. Of course, changing our bug tracker alone won’t automatically structure our activities, but it is a step in this direction.

Recommendation: Use tools that allow a better management of, and integration between, the different stages in our product(s) lifecycle.


A few months ago, I asked Priyanka Dhanda (our new Code maintenance engineer) to explore open-source collaborative project management platforms that could be easily integrated with bugzilla (or that included a bug tracking system of their own). The Wikimedia tech community was invited to list requirements of such a tool, as well as possible solutions.

From the feedback we received, we can summarize what the required features for an issue tracker are: integration with our Version control system, being FLOSS, multiple projects support and ability to separate between “tasks” and other items such as bugs and feature requests. Additional, “nice to have” features include: ability to import data from existing Bugzilla instance and fined-grained e-mail subscription options

Similarly, the required features for a Project management tool are: being web-based to facilitate collaboration, multiple projects support, calendar/scheduling and roadmap, assignments & resource management and time tracking per task/user/project. Additional, “nice to have” features include: Gantt charts, public/private projects, fine-grained access to projects by user, basic accounting & budget management and requirements management.


I haven’t found many Project management softwares that can be easily integrated with Bugzilla. However, I have discovered alternatives to Bugzilla that include project management features like those we’re looking for. Redmine seems to be a good project management software and provides an advanced issue tracking system as well. It supports multiple projects, public/private projects, calendars & Gantt chart, and a lot of other neat stuff.

It also offers the ability to distinguish between features/improvements and bugs; this would be particularly useful to prioritize development efforts. We are now considering using Redmine as project management software and taking this opportunity to move our Bugzilla setup to Redmine. Initial research shows that a lot of people seem to praise Redmine compared to Bugzilla; there are migration scripts to import an existing Bugzilla setup into a new Redmine one.

Major projects such as TYPO3 are using Redmine. The software seems to benefit from a dynamic community of developers and it is also possible to sponsor custom development. There are many plug-ins to extend the default core features; popular plug-ins are usually included into the core software at some point.

Priyanka set up a local test instance of Redmine to let us play with it a bit; a public test platform was later made available for wider testing and the Wikimedia Tech community was invited to pitch in. So far, I personally like it and it fits my needs perfectly. Wider testing is now necessary to see if it fits the needs of the tech community.

Because the time I can devote to this change is limited, I haven’t reviewed other alternatives than Redmine, and don’t plan to unless another major alternative is suggested.

Recommendation: Move from Bugzilla to Redmine after careful preparation, especially regarding the organization of the platform.

Scaling up Software development for Wikimedia websites

Our human resources are currently focusing on what happens after the code has been written: we review it, we try to ensure quality, we try to automate testing, we file bugs, etc. However, there is little preparation before the development is actually done. This has led to a developer-driven design, resulting in an interface based on the implementation model. We need a more systematic approach to User experience and development management if we want to scale up properly.


Brighton Uni Usability Lab by Danny Hope, under CC-By, from Wikimedia Commons.

Product management & Design

In the Software development world, Product managers and Designers are the most common bridges between users and engineers. Product managers identify the needs of users and prioritize features & improvements; their goal is to translate the users’ experience and feedback into explicit requirements to meet the users’ expectations. It is then the role of the designers to create innovative, well-thought solutions to address these issues and meet the requirements. Finally, developers provide feedback about the technical feasibility of these solutions, and implement them the best way possible. This is of course a simplistic summary, but it helps get the point across.

Designer” can have a lot of different meanings. A lot of people think that “design” is just making things pretty. When I talk about designers, I think mainly of Interaction Designers, i.e. people who design solutions to improve the user experience and the way the product interacts with the user.

The community of MediaWiki users is amazingly large, partly because they include participants from all Wikimedia Websites. Similarly, MediaWiki also benefits from a large base of volunteer developers. Product managers and designers have been the missing piece in this picture; their bridging role is critical, simply because there aren’t any volunteers to take up this task. Admittedly, some users are also developers, and some developers keep themselves informed of the users’ wishes. But without product managers, clear requirements & prioritization are missing. And without designers, the technical solutions created by the developers don’t meet the users’ expectations and mental model.

In my experience, developers prefer to focus on the actual development and rarely enjoy meta-activities related to it. They usually dislike project management and writing product specifications, and rightly so: it is not their job. However, a successful software product strategy cannot rely only on development.

We benefit from a large community of volunteer developers, but we lack management & design resources; it is the role of the Foundation to supplement this lack. It doesn’t mean we shouldn’t expand our development team: our number of paid core developers is ridiculously small. It only means we should also invest where the weakness lies.

Recommendation: Recruit Product managers and Designers to strengthen the development cycle of our technological platform

Research team

The Multimedia usability project has relied heavily on initial research in order to gather as much information as possible about users and their goals. A lot of useful information was already available, but a lot of specific metrics were also missing; collecting and analyzing them took a lot of time and it will still take months to get all the metrics we need.

Research is critical in order to make the right decisions, especially about design. Research is the only way know our users in order to make the best design & management decisions. Good research is the best basis on which product managers, designers and developers can then respectively specify, design and build awesome solutions.

Right now the only researcher we have is Erik Zachte as Data analyst, but his job seems to essentially focus on providing operational metrics. While this work is much needed, we also need some more specific data on a case by case basis. I see at least three other positions needed:

  • A UX research specialist, who would conduct regular in-house low-cost usability testing, and generally manage UX studies

  • A Metrics engineer, who would develop integrated metrics in the software and be able to extract specific information from the database on a case by case basis.

  • A Community specialist, with a good knowledge of social psychology and online interaction, who would especially focus on improving the interaction between participants by identifying the community issues and proposing ways to fix them.

Recommendation: Build a Research team to guide design & strategic decisions about our technological platform

Volunteer developers

We benefit from a fantastic community of volunteer developers, but we underestimate their potential; I think we are not doing enough to support their work and engage them into our activities. In 2007, the Foundation hired Cary Bass to try and coordinate the large pool of volunteers willing to help us with meta activities.

Similarly, we need a Developer community manager to care for our volunteer developers. We need someone who knows the developer community very well, and knows their strengths and weaknesses in order to find the right person for each job. We need someone who can help orient new volunteers, organize real-life meet-ups and manage projects such as the Google Summer of Code.

Recommendation: Recruit a Community manager to coordinate the efforts of volunteer developers.

Wikimedia User experience programs

Over the years, the design of MediaWiki has been solely driven by software developers. This has caused an unfortunate technology-based approach of the front-end and the features (implemented or missing), relying mostly on the implementation model. The consequence is that the interface & features are too far from the users’ mental model.


Japanese Tea pot by Denis Savard, under CC-By, from Wikimedia Commons.

UX should be a systematic approach

The Wikipedia and Multimedia Usability projects have tried to address the most pressing concerns resulting from the hiatus between the software and the users’ expectations. For all these reasons, I am really happy to see the Wikimedia Foundation investing further in User Experience (UX). However, I see little added value in having a UX department separate from the main development cycle.

A more systematic approach is necessary in order to improve the usability of Wikimedia projects perennially; good, usable design needs to happen before the actual implementation of any feature, in the early stages of the product (or component) development. Otherwise, we will always be running after the train, and never catch it.

A separate group made sense when these UX programs had a specific scope and time frame, but it was because they were tied to specific grants. In a more permanent setup, I see no reason to separate UX programs from the “regular” development processes; targeted actions can be carried out by specific projects inside the development team, rather than by a separate team altogether.

Everything is UX

More generally, all the activities of our Technology department are about User experience; everything we do is UX. Software development aims to fix bugs, develop new features, improve others, and remove hindrances. The sole goal of all of these activities is to improve the user experience by making the software better and closer to users’ needs. Even Operations are about UX: the goal of the Operations team is to make sure the information can be accessed reliably and reasonably fast by an audience as large as possible; in short, the point of Operations is to ensure we actually provide a user experience.

As a consequence, I recommend to make UX a systematic part of the product or component development cycle, not a separate parallel group.

Wikimedia and MediaWiki bugs, issues, and requests

Over the past few weeks, I have been thinking about how to improve (or rather, kick off) a more structured way to manage software and product development within the Wikimedia community. The result is a list of ideas and recommendations I have compiled and submitted to the relevant staff members at the Wikimedia Foundation. I am also publishing them here in order to allow for wider feedback. This article is the first of a series dedicated to this topic.


Bug on Sunflower Petal #1 by Ryan Poplin, under CC-By-SA, from flickr.

Tool-agnostic naming

Right now, the bug tracker we use is based on Bugzilla and located at Many major free projects use a generic “bugs” or “issues” prefix or suffix in their URL:,,, Some projects use the “bugzilla” prefix like we currently do, like The latter is an example of a choice based on the implementation model: the name reflects the technical implementation of the bug tracker, not its actual purpose. A better name would be closer to the user model and describe the actual goal of the platform: to report and manage bugs and issues related to a specific project. If we do change our tracker, the current name will have to change too, because it is specific to a given tool.

Recommendation: Use a generic descriptive prefix rather than one based on the tool we use.

Wikimedia & MediaWiki

Another current issue is the confusion caused by the similar names used for the organization (Wikimedia) and the software (MediaWiki). A good example of this confusion is the number of MediaWiki users who join the #wikimedia IRC channel instead of #mediawiki to ask for software support. The confusion is even worsened by the fact that we have a unique bug tracker located at, dealing with issues related to both Wikimedia websites and the MediaWiki software.

There are obviously strong ties between Wikimedia projects and MediaWiki: all Wikimedia projects use the MediaWiki software, and the MediaWiki software is primarily developed with Wikimedia projects in mind. However, there is also a growing community of MediaWiki users who are not Wikimedia users and we should provide them with tools relevant to them. This might be for instance a support forum dedicated to MediaWiki users.

Wikimedia projects and MediaWiki are separate products and they should be acknowledged as such: as a consequence, the separation between bugs in the MediaWiki software, and Wikimedia-specific operations & configuration requests should be made more explicit. Obviously, we would prefer to have a unique back-end to support both sites, particularly to be able to move bugs and requests from one platform to another, but this is easily configurable. Possible names could be and; both are currently unused. They are pretty wide prefixes, because we may host a real project management platform there, rather than just bug trackers.

Recommendation: Offer two different public-facing platforms for MediaWiki- and Wikimedia-related issue tracking.

Help us collect good ideas to improve Wikimedia Commons

Do you regularly use media sharing platforms like Flickr, Youtube, Fotopedia, Picasa web or Panoramio? Then you can tell us what you love (or hate) about their interface and features, to help us improve Wikimedia Commons.

As part of the Wikimedia Multimedia Usability project, we are currently doing what is called Domain research. Basically, it means that we look at how similar websites work and how they deal with the same issues we encounter. Since our goal is to make Wikimedia Commons more usable, we want to look at other media sharing platforms, such as Flickr, Youtube, Fotopedia, Picasa web, Panoramio, etc.

I would like to ask for your help to accomplish this research. It can take a lot of time if only one person is doing it. On the contrary, if ten or twenty people step in and all do a small part, we can collect helpful data very quickly. Besides, it is always better to have several people with different perspectives look at the data we collect, in order to better see the “big picture.”

Your help is crucial in order to move quickly towards the requirements definition phase. I have already prepared a list of websites and a few questions we are asking ourselves; they should facilitate the collection of data that can then be used directly by the team.

Please join us and make your contribution to the Domain research page on the Usability wiki.

Ten features that would dramatically improve Wikimedia Commons

Where our hero makes an early Christmas wishlist and implores the developer fairies to give Wikimedia Commons some much-needed love.

MIT’s Technology Review recently published an article about improvements to come regarding the management of video content on Wikipedia and Wikimedia websites. I heard a lot of people say: “Good, but what about pictures?” Some technical improvements described by the Technology Review will be useful for both images and videos, such as the media and upload wizard currently developed by Michael Dale. However, Wikimedia Commons still needs many little (or big) features that would dramatically improve its user-friendliness.

Browsing & reusing

  1. Automatic localization: Websites such as Wikimedia Commons and meta-wiki host content in various languages and have a multilingual audience. These multilingual wikis should automagically detect the locale of the user’s browser and use it as language of the interface, especially for unregistered users. As for users with an account, their browser’s locale should be set as the default language in their preferences.

  2. Usage-centric page layout: It’s all very nice to know that such image is a “retouched picture” or that such diagram was “made using Inkscape.” But I think what most of the users want to know is: how to use the picture (in Wikimedia projects or elsewhere) and how to download it (using the best resolution available). Many people use the right-click-save-as method to save pictures from the Internet. If they do that on Commons, they will only save the low-resolution preview. There should be a big button « Download high-res », as well as snippets of code to embed a file with proper attribution.


Full metadata support is the cornerstone of many other features. EXIF is probably the most known type of metadata, but there are also others such as IPTC or XMP.

  1. Pull metadata from files on upload: this idea is not a new one, yet it hasn’t been implemented. A fair amount of photographers add a lot of metadata to their files: author, description, copyright information, geotags, keywords, etc. and it is extremely cumbersome to have to redo all the work by hand during the upload.

  2. Store metadata in a database to make search and attribution easier, especially: description, license, media type (photo, diagram, map, etc.). It should be connected to the MediaWiki API to allow for easy extraction of these data.

  3. Push metadata to files on download: In the field of publishing, storing credit information directly into the file’s metadata is strongly recommended and is a standard practice to avoid losing track of it.


  1. Built-in basic editing features (lossless rotate, crop) and ability to save under another name (i.e. for crops). Similarly, a built-in geocoding feature using OpenStreetMap. Geocoding images means attaching geographic information about the place where the work was made. This may be made easier by the current initiative to integrate OpenStreetMap with Wikimedia projects. And of course it should save the coordinates as metadata.


  1. Some sort of community-managed rating feature; as someone said elsewhere, “Commons is a depository, and depositories are expected to host lots of junk.” A rating feature would allow the best of Commons to be presented first during the search, and junk to be presented last.


With currently more than 4.6 million files (and counting), it is becoming increasingly important to improve the search features of Wikimedia Commons.

  1. An “advanced search” feature similar to flickr’s. It should be possible to search by media type, by license, and to add toggles such as “safe mode” (explicit content) or “personality rights.”

  2. Multilingual search: Files on Commons are ordered in hierarchical categories, using English as lingua franca. If you want to find a file, you have to search in English. I imagine it is possible to use some dictionary (coupled to the language detection) to give good results for a search in any language.

  3. Google-Images-friendliness. A lot of people use Google Images to find pictures, but images from Wikimedia Commons rarely appear in these results (unless they are used on a Wikipedia page).

Five fundraising tips for Wikimedia chapters

Last year, I started to learn about fundraising. Originally, I did it because I intended to use what I would learn to improve Wikimedia France’s management of fundraising. I eventually distanced myself from Wikimedia France for various reasons, but I figured I’d still share a few thoughts that may prove useful to all chapters. Although this article is mainly Wikimedia-focused, the general principles are universal.

1. Do your research

You can’t just improvise fundraising. You’re asking people their money: you have to do your research and behave professionally.

Raising funds is like drawing: it’s not a matter of innate talent. Some rare people are naturally good at it, but most people have to learn and practice regularly in order to be really good at it. The good news is that you don’t need to learn a lot to be good enough to see a noticeable change in your income; it may not follow the Pareto principle, but it’s still good news.

There are many books about fundraising out there. Here’s a list of books I own and I have read. They’re short and very good to begin with.

If you follow their principles, I guarantee you’ll raise more funds. I recommend you read them in this order. Experiment your newly-acquired knowledge during a few months, adapt it to your organization, and keep learning. I’d be happy to provide more links if needed.

2. Apply what you’ve learned

Learning is the first step; it’s mandatory but useless if you don’t apply what you’ve learned to your specific organization, your mission and your message. These books provide you with a variety of tools and with food for thought, but I suggest to take each principle or piece of advice and see 1. if it applies to you (most do) and 2. how you can apply it.

I’ve found the following modus operandi to be very effective: While you’re reading the books, ideas and thoughts about your own organization will pop up in your head. Write them down as you would brainstorm: write everything even if it looks stupid. But focus on discovering and learning and don’t try to apply it right then. When you’ve read several books, your perspective will have changed and you’ll be more knowledgeable about fundraising already. Read the books again, but this time focus on how you can apply what you’re reading to your own organization and mission. During the first pass, you’re in the learning phase; during the second pass, you’re in the thinking/applying phase, and the books are merely reminders.

3. Understand the importance of raising funds

Don’t try to raise funds because you “should” or because “it’s nice.” Raise funds because you need money. You can never be as convincing when you ask as when you’re passionate about a project you know you can’t accomplish unless you collect the needed amount of money.

You may see fundraising as a difficult activity that doesn’t bring in a lot of money. You may consider other means to collect money (such as selling goodies) because you see them as easier ways to earn money. Considering alternate means is good, but selling T-shirts won’t (and shouldn’t) be your primary source of money. Ever.

You’re nonprofits; that means you should rely on donations and grants. If you don’t learn about fundraising, you may not fully understand its potential. During the Wikimedia Conference in Berlin, Liam Wyatt likened the Wikimedia movement to a “Red cross for knowledge”: people will donate to you if you ask the right way.

4. Cherish your donors

Thanking your donors one year after they donated is completely unacceptable. If you do only one thing, thank your donors and stay in touch. You can’t afford to lose them. When you’ve read a bit about donor relationship management, you’ll understand how foolish this is.

Also, try to walk in your donors shoes (“donor-centric approach”). Why should I give to these Wikimedia folks?

5. Spend your money

The best way to raise funds is to spend your money. Donors don’t give you money so it lingers on your bank account. They give you money so you do things; they want you to accomplish things to make the world better on their behalf. There is no such thing as “waiting for more money before spending it.” If your projects require more money, then raise more money. If you don’t have any projects to spend your money on, you’re in big trouble. Fortunately, my next article will be about just that: how to spend your money.

Wikimedia PR material cleanup

In an effort to consolidate PR materials about Wikipedia and Wikimedia, we’re starting an inventory of all known materials in all languages. You can help by adding items to the inventory, to make sure we don’t miss anything.

Casey Brown and I have decided to revive the PR material cleanup project. This project was started by Sean Whitton as a ComProj initiative in August 2008, but it slowly died of inactivity. This time, fewer people are involved, but hopefully they’ll commit more time to this much needed project. This project is the first step of a major revamp of PR materials related to Wikimedia projects. We’re currently in the middle of the inventory, which includes a very needed assessment of out-of-dateness of all documents.

The main goals are to:

  • identify and archive obsolete documents that could alter or damage our image

  • dentify all kinds of PR, marketing & outreach documents that could be useful.

For example, I know that hosts a press book with press articles about Wikimedia projects. This is perfectly fine on, since as archives they can’t be obsolete, and we wouldn’t import them on meta because our local EDP doesn’t allow them. So, this kind of stuff can be skipped in the inventory :) However, if you are aware of presentations, posters, cheatsheets, leaflets, handbooks, etc. that are not listed already in the inventory, that’s what we want :)

We listed the wikis that are the most likely to host PR material, but if you are aware of others, please add them.

This message aims at:

  • asking you to add any document or page you’re aware of to the inventory, if it’s not already there;

  • letting you know that this cleanup is being done and that a major revamp is the next step.

  • if you have some time, asking you to help us with the ruthless job of finding, describing, labeling and assessing all PR materials :) We’re also counting on the ComProj members for that.

Thanks for helping out!