Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Posts by Guillaume Paumier

Wikimedia engineering report, March 2014

Major news in March include:

  • an overview of webfonts, and the advantages and challenges of using them on Wikimedia sites;
  • a series of essays written by Google Code-in students who shared their impressions, frustrations and surprises as they discovered the Wikimedia and MediaWiki technical community;
  • Hovercards now available as a Beta feature on all Wikimedia wikis, allowing readers to see a short summary of an article just by hovering a link;
  • a subtle typography change across Wikimedia sites for better readability, consistency and accessibility;
  • a recap of the upgrade and migration of our bug tracking software.

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.


A young developer’s story of discovery, perseverance and gratitude

This post is a discovery report written by Jared Flores and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

When I initially heard of the Google Code-In (GCI) challenge, I wasn’t exactly jumping out of my seat. I was a little apprehensive, since the GCI sample tasks used languages such as Java, C++, and Ruby. While I’ve had my share of experience with the languages, I felt my abilities were too limited to compete. Yet, I’ve always had a fiery passion for computer science, and this challenge presented another mountain to conquer. Thus, after having filtered through the hundreds of tasks, I took the first step as a Google Code-In student.

The first task I took on was to design a share button for the Kiwix Android app, an offline Wikipedia reader. Though Kiwix itself wasn’t a sponsoring organization for GCI, it still provided a branch of tasks under the Wikimedia umbrella. With five days on the clock, I researched vigorously and studied the documentation for Android’s share API.

After a few hours of coding, the task seemed to be complete. Reading through the compiler’s documentation, I downloaded all of the listed prerequisites, then launched the Kiwix autogen bash file. But even with all of the required libraries installed, Kiwix still refused to compile. Analyzing the error logs, I encountered permission errors, illegal characters, missing files, and mismatched dependencies. My frustration growing, I even booted Linux from an old installation DVD, and tried compiling there. I continued this crazy cycle of debugging until 2 am. I would have continued longer had my parents not demanded that I sleep. The next morning, I whipped up a quick breakfast, and then rushed directly to my PC. With my mind refreshed, I tried a variety of new approaches, finally reaching a point when Kiwix compiled.

With a newly-found confidence, I decided to continue pursuing more GCI tasks. Since I had thoroughly enjoyed the challenge presented by Kiwix, I initially wanted to hunt down more of their tasks. However, finding that there weren’t many left, I gained interest in Kiwix’s supporting organization: Wikimedia. I navigated to Wikimedia’s GCI information page and began familiarizing myself with the organization’s mission.

“We believe that knowledge should be free for every human being. We prioritize efforts that empower disadvantaged and underrepresented communities, and that help overcome barriers to participation. We believe in mass collaboration, diversity and consensus building to achieve our goals. Wikipedia has become the fifth most-visited site in the world, used by more than 400 million people every month in more than 270 languages.” – About Us: Wikimedia (GCI 2013)

Reading through the last sentence once more, I realized the amazing opportunities that were ahead of me. Whenever I needed to touch up on any given topic, Wikipedia was always one of the top results. Moreover, Wikipedia had become a source of entertainment for me and my friends. We always enjoyed hitting up a random article, then using the given links to find our way to Pokémon, Jesus, or maybe even Abraham Lincoln: Vampire Hunter.

Eager to begin, I chose video editing as my second task for Wikimedia. I began the long endeavor of watching, reviewing, and editing the two forty-five minute clips. Despite the lengthy videos, I was quite amused in seeing the technical difficulties that the Wikimedia team encountered during their Google Hangout. It was also comforting to put human faces behind the Wikimedia mentors of Google Code-In.

As with my first task, the work itself sped by quickly. But also similar to Kiwix, I encountered some difficulties with the “trivial” part of the task. I had never worked with the wiki interface before, so the wiki structure was somewhat foreign. I only had a vague idea of how to create a page. I also didn’t know where to upload files, nor did I know how to create subcategories. Nonetheless, after observing the instructions in Wikipedia’s documentation, I finally managed to upload the videos. Marking the task as complete, I scouted for my third GCI task.

Unbeknownst to me, my third task for Wikimedia would also prove to be the most challenging so far. Since this task required me to modify the code, I requested developer access. With the help of Wikimedia’s instructions, I registered myself as a developer, generated a private key to use with their servers, and proceeded to download the source code.

Though my experience with Git was quite basic, MediaWiki provided an easy to follow documentation, which aided greatly in my efforts to download their repository. As I waited for the download to complete, I quickly set up an Apache server for a testing environment. Configuring the MediaWiki files for my server, I began the installation. Fortunately, MediaWiki’s interface was quite intuitive; the installer performed flawlessly with minimal user input.

“Off to a good start,” I chuckled quietly to myself, a grin spreading across my face. And with that statement I tempted fate and my troubles had begun. Upon opening the code, I realized I couldn’t easily comprehend a single line. I had worked with PHP but the code was more advanced than what I had written before.

Running my fingers through my hair, I sighed in exasperation. I spent the next few hours analyzing the code, trying my best to decipher the functions. Suddenly, patterns began appearing and I began to recognize numerous amounts of functions. I started to tinker with different modules until the code slowly unraveled.

Finally formulating a solution, my fingers moved swiftly across the keyboard, implementing the code with ease. Confident that I had tested my code well, I followed the instructions written in the GCI’s task description, and uploaded my very first patch to Gerrit.

I was surprised at how simple the upload was. But what especially surprised me was the immediate feedback from the mentors. Within a few minutes of the upload, MediaWiki developers were already reviewing the patch, making suggestions for improvement.

Thankful for their helpful input, I worked to implement the changes they suggested. Adding the finishing touches, I was ready to upload another patch. However, I was unsure if I should upload to a new Gerrit, or if I should push to the same patch as before. Unclear about the step I should take, I made the rookie error of uploading to a new Gerrit commit.

My mistake quickly received a corrective response from Aude via the Gerrit comment system. While I initially felt embarrassed, I was also relieved that I didn’t have to work alone. In fact, I was thankful that the MediaWiki collaborators taught me how to do it right.

Checking out the link Aude had given me, I learned to squash the two commits together. However, when I tried to follow Aude’s instructions, I somehow managed to mix someone else’s code with my own. What’s even worse was I already pushed the changes to Gerrit, exposing my blunder publicly.

Had it been any normal day, I would’ve just been calm and tried my best to fix it. But it just so happened to be the Thanksgiving holiday (in the United States). I had to leave in a few minutes for a family dinner and I couldn’t bear the thought of leaving my patch in a broken state.

I felt about ready to scream. I abandoned my Gerrit patch, and navigated to the task page, ready to give up. But just as I was about to revoke my claim on the task, I remembered something Quim Gil had told another GCI student:

“They are not mistakes! Only versions that can be improved. Students learn in GCI, and all of us learn every day.”

Remembering this advice, I cleared my mind, ready to do whatever it would take, and learn while I was at it. And like an answer to my prayers, Hoo Man, another developer, posted a comment in Gerrit. He guided me through how I could return to my original patch and send my new improvements through. And more importantly, he motivated me to persevere.

I came into GCI as a passionate, yet undisciplined student. I’m thrilled that in joining this competition, the Wikimedia open source community has already helped me plant the seeds of discipline, perseverance, and collaboration. It’s no coincidence that my hardest task thus far was staged on Thanksgiving. Every year I express gratitude towards friends and family. But this year, Google Code-In and the Wikimedia community have made my gratitude list as well.

Jared Flores
2013 Google Code-in student

Read in this series:

Discovering and learning by asking questions

This post is a discovery report written by Vlad John and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

In the past years, I’ve used Wikipedia as often as I’ve used Facebook. I’ve used it for homework or simply for finding something new. When I was first introduced to the Internet world, I always asking myself: how can someone make a site with so many people browsing it? This year, I found the answer at the Google Code-In contest. As I was browsing for a task that suited me, I found an organization called Wikimedia.

While browsing the tasks they offered, I found something that caught my eye. It was a task about editing the wiki. I was so happy that I had finally found a task that suited my tastes that I clicked “Claim Task” before reading what I had to do. But when I read more about specifics of the task… well, it is enough to say that I had no idea how to start. I was supposed to “clean up” the “Raw projects” section of the Possible projects page. I clicked the link to the wiki page I was supposed to edit, and as I started working, I encountered several problems that I will describe in a moment. But thanks to my mentor, Quim Gil, I succeeded in completing the task.

I always wanted to edit a Wiki page, but at first I was afraid. What if I did something wrong? After posting a text file on the Code-in task’s page, I received a comment that said that in the end I’d need to edit the wiki page itself, so I might as well start early. This made sense, so I dove into the unknown territory of editing.

I started by looking at the history of the page to find the things I had to add. That took a while, but in a shorter time that I first thought was necessary, I learned how to find information in earlier edits, how to edit the source code of the page and how to do minor edits on the headings and structure. But this was the easy part.

I just had to copy some names and move them to their appropriate place. However, when it came to reporting bugs, I was indeed lost. I knew from the task I had to use Bugzilla to report bugs and add comments, but I didn’t have the foggiest idea how to do it. That is when I started doing what I had to do in the first place: ask questions.

I realized that the whole point of this exercise was to teach students how to do different things, and the most important thing when learning is to ask questions everywhere: on forums, consult the FAQ or the Manual , or simply search more for the answer. So I began by reading the full Bugzilla guide, but that did not really answer my questions. At least, not until I found the “How to report a bug” guide. This gave me some important information, like what to look for and how a report should look.

But I still had one problem: the guide said a thing and the mentor said something else. So I decided to ask once more on the page of the task. In no time, I received an answer and a model. Apparently, the guide was right about one part of the task, and the mentor was right about another part. So, by combining the answers from these two sources, I managed to find the answer to my problem. Once I knew what I was looking for, and once I asked the right questions, I got the answers I needed.

From there, it was not too hard to start adding and commenting bugs on Bugzilla. The next problem appeared when I had to add the bug reports on the wiki page… I thought I was done the moment I added the bugs on Bugzilla, but again my lack of attention and knowledge got the best of me. So I told myself: If asking the right question gets me the information I need, why not ask again? After all I am here to learn.

So I went back to the task page and put another 2 paragraphs of questions. Indeed, I received the answers that helped me learn something about editing the source of the page. So I dove in once again in the unknown and started the work. After a hard time finding the bug reports again, I was finally done and I completed the task.

After finishing, I realised that a person can learn anything on his or her own, but learning is more effective if a mentor or teacher helps you. Also, a teacher that just tells you what to read and does not explain is less helpful than a teacher that knows how and what to explain, when to do it and speaks to you in a nice way, and by that helping you, like Quim Gil helped me, with explanations and examples, in completing the task.

So, to sum up, if you ever want to learn something about Wikimedia (or other things), the best way is to ask other people, be he or she a mentor like Quim Gil was for me, or a complete stranger on a forum, like StackOverflow, which is an important place for coding and scripting help. Many people say that learning has no shortcuts, but, if questions are not shortcuts, then they sure are a real help in education. Why? Because with questions come information, and with information comes knowledge.

Vlad John
2013 Google Code-in student

Read in this series:

A junior developer discovers MediaWiki

This post is a discovery report written by Coder55 and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

I’m a 17-year-old boy from Germany interested in computer science. I write my own little programs in PHP, Python and Java and have even produced some Android apps. I completed a Python course in three days, and now I’m using Python to solve math problems. I heard about Google Code-in on a German news site for young people interested in computer science.

Account creation and language selection

The instructions for Google Code-in students were easy to understand, even for people who aren’t so good in English. After that, I created an account on The registration form looked modern; I wanted to take the user name ‘Coder55’, but it was already taken so an account creation error was displayed. The text I typed in for password and email were deleted after the error; maybe it could be saved in a session variable and written into the text fields via JavaScript.

After registering and logging in, I saw many different options in the top line. It was easy to change the language and to read my welcome message. Maybe the button with the text ‘log out’ could be replaced by a logout button with a little picture, to make the top line smaller and even easier to understand.

After that, I changed the language to German and Spanish because I wanted to see how much of the site had been translated. I was quite disappointed that only the top menu was completely translated. The left sidebar was not completely translated, even though many important links can be found there, like one to the Main Page. I was also surprised that the language of the content on the page didn’t change after I changed my language options: if I’m on the Main Page and I change the language to German, I still see the Main Page in English, although the left menu has partially changed to German. This puzzled me until I found out I had to click on ‘Hauptseite’, ‘Página principal’ etc. to see the Main Page in another language.

How to become a MediaWiki hacker

I am really interested in Developing, so the next thing I did was visiting the How to become a MediaWiki hacker page, where I found interesting tutorials that explained how to develop something on the MediaWiki platform. The page was clearly arranged and I really liked it. It clearly separated the required abilities (PHP, MySQL e.g.) and made it easy to see where I needed to learn something and where I already knew enough. The ‘Get started’ part was particularly helpful: I could start quite fast extending MediaWiki.

One thing that was missing for someone like me: example code of a really easy extension. Although all the aspects of developing are explained in detail in the Developing manual, seeing those easy extensions requires to follow several links; it would be really helpful for beginners to include and explain one or two of these examples in the manual.

I had already been programming some little programs in PHP (chat server, forum etc.) so the next thing I did was to study MediaWiki’s coding conventions; they were explained clearly and were easy to understand. The ‘C borrowings’ part was really interesting.

Around MediaWiki: API, bugzilla, git and Wikitech

Unfortunately, I didn’t find the video on the API page very helpful. The pictures were blinking and the voices hard to understand. But the rest of the API documentation was really informative and easy enough to understand.

After that, I looked at the “Development” section of the left sidebar. I visited the Bugzilla overview, and then the actual site. I really liked the idea of Bugzilla, where every developer can see where help is needed. However, if you don’t know specifically, what to look for, the search function in Bugzilla isn’t very helpful[Note 1].

I then clicked on the link called ‘browse repository’. I was positively surprised by what the site looked like. I especially liked the possibility to see which parts of MediaWiki had been just updated. I also took a look at at Wikitech; The Main Page looked really similar to Wikipedia and MediaWiki, so it seemed easy to navigate.

The Pre-Commit Checklist

On the next day, I read about how to install and configure MediaWiki. The documentation was clear and easy to read, but I didn’t understand all of it, probably because I’m more interested in developing than in hosting.

Following this, I looked into more details about developing at the Developer hub. I had already studied the coding conventions, so I started reading the Pre-Commit Checklist.

This checklist contained many questions, but for someone like me who hasn’t already uploaded code there, they are partially not understandable. The part about Testing was clearer for me because it was explained a little bit more. Maybe the questions in the checklist should be written in a little more detail, or some of the difficult words should be converted into links.

I liked having an overview over all conventions at the bottom of the page. I could easily navigate to another convention list, like the coding conventions for JavaScript. These conventions were explained in detail and with clear examples. I especially liked the part about whitespace where many rules have been written clearly and concisely.

In conclusion

MediaWiki is a very interesting platform and although some things are not perfect (e.g. translation or registering form), it is easy to join the community. The most active contributors are accessible on IRC, which makes communication easier. After discovering the technical world of MediaWiki, I’m really interested in getting involved into the community, although that will need to wait until I finish school.

2013 Google Code-in student

  1. Editor’s note: Bugzilla has since been upgraded, and its main page now features common search queries.

Read in this series:

Through the maze of newcomer developer documentation

This post is a discovery report written by David Wood and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

This discovery essay touches on my general thoughts as I initially started to browse and look into developing for MediaWiki.

I’ve split it into three sections: Setting up, where I cover my experiences while working with pywikibot for a previous Google Code-In task; First Impressions, where I describe my thoughts as I browse the documentation geared towards newcomers; and Developer Hub, where I describe my thoughts as I venture into the actual development articles.

Setting up

Before looking to develop for MediaWiki, I had previously completed a task relating to pywikibot. I found that the mentors were very helpful and available for advice.

However, I did find issue with setting up the development environment for work on pywikibot. It seemed very complex, and at first I did not fully understand what I was required to do. For someone who hasn’t worked on large-scale projects before, such as MediaWiki, I was confused as to why it was required to have so many accounts and things set up beforehand, such as a Gerrit account.

Although I now understand, I feel that a guide explaining to newcomers, not necessarily new to collaboration with git, but to using less known tools such as Gerrit, why they are necessary, would be helpful. And although I understand that in some cases not much can be simplified as setup is complicated, perhaps a more in-depth guide would help as well (keep in mind, this is referring to the guide for installing pywikibot, and the guide for MediaWiki in general may be better).

First impressions: a guided tour for newcomers

Coming from only basic experience with a small project within MediaWiki, I was pleasantly surprised with the quality of the information and simplicity of it from the How to become a MediaWiki hacker page. There was a lot of information, for example, instead of simply telling the reader that they required knowledge in PHP, MySQL and JavaScript, the guide went on to link them to where they could gain such knowledge.

From there, I went to read A brief history and summary of MediaWiki. This was especially interesting as not only was it a engrossing read, it also helped the user understand the principles under which MediaWiki is developed, such as the fine line between performance and functionality. Such information helps a new user, such as myself, understand the goals behind MediaWiki and the mindset in which I should be working.

Another pleasant surprise was that even the more technical articles, such as Security for Developers, were written in plain English, without a lot of technical language. And even where it got technical, it was explained well. Guides that have a lot of importance, such as this one relating to Security, benefit even more from being simple for newcomers than most, as it’s more likely then that a newcomer would understand and implement what they’ve learnt.

Another note I made was that all the links that would be relevant to newcomers, such as Coding Conventions, were all easily found.

Developer Hub: What next?

My next stop was the Developer Hub, where I found that I wasn’t sure how exactly to proceed. There, unlike the last article, didn’t seem to be a clear path to follow when traversing the article, most likely due to this article not being geared directly towards newcomers to MediaWiki.

This is where I experienced most issue; from here there was no more crutch helping me along. I somewhat expected, as I had seen on other projects, there to be a simple guide for what to do next for newcomers and, unless I couldn’t see it, there wasn’t one. I was left unsure as to what to do next; Should I just start browsing code? Look at feature requests? Or for bugs? I think this is where some guidance would be helpful for newcomers; getting to this point was well documented, but after you’ve set everything up, you’re left wondering what next. Some sort of list of easy bugs, or projects for newcomers to contribute to, would give some guidance as to what type of contributions they should be looking to make next.

I also noted that some information linked from the developer hub, such as an archived roadmap, was out-of-date or marked as only available for historical purposes. While I understand the reasoning behind this, it’s still confusing as these links are still prominent on the page.

In conclusion

While I didn’t install MediaWiki personally, my experiences toward the complexity of setting up things, as detailed in the first part, where from a pywikipediabot perspective, as I come from a python background rather than a PHP background. I would consider however contributing to MediaWiki in the future, if I ever take time to learn PHP, as it not only seems a enjoyable experience, but I appreciate the ideologies behind MediaWiki, to support a community that creates and curates freely reusable knowledge on an open platform.

David Wood
2013 Google Code-in student

Read in this series:

Tech discovery report: What is this Wikitech thing anyway?

This post is a discovery report written by Ashwin Bhumbla and slightly edited for publication. It’s part of a series of candid essays written by Google Code-in students, outlining their first steps as members of the Wikimedia technical community. You can write your own.

I am not the best with computers.

Upon arriving on the MediaWiki and Wikitech home pages, I was instantly lost. For a while, I tried clicking links to see if they would lead to any information as to what the purpose of these communities actually was. However, my searches always led to pages with lines of code that might as well be Latin to me. Now, I’m pretty sure that my confusion was due more to my inexperience than anything, but the pages didn’t help much either.

My first objective was to try to find out the purpose of each site. Both sites had a kind of mission statement on the front page, but that didn’t offer that much information at first. was slightly easier to figure out; it offered multiple pages on what the purpose of the wiki was and how to join. I was pleased that even though MediaWiki seemed impenetrable, it had pages specifically for new users, helping them become an active part of the community.

Sadly, the same could not be said for Wikitech. I understand that the wiki is a hub for documenting and fixing all bugs related to the MediaWiki software[Note 1], and as a result doesn’t really need to be all that welcoming and user-friendly. And it showed. As a newcomer, I had absolutely no idea what I was doing, or what to do. I understand that the wiki is only for those who have already been initiated into the wiki community, but it would be nice to have some pages dedicated to explaining the site’s layout and how one could contribute to it.

As you can probably tell, I favored MediaWiki over Wikitech when it came time for my research. It is a much more informative and newcomer-friendly wiki. is for people who are just starting, whereas Wikitech is for people who are already integrated into the community. I would advise anyone who is a newcomer like me not to be turned off by the lack of accessibility of the wikis.

While Wikitech is still a daunting and, in my opinion, not-that-well-organized of a wiki, MediaWiki is a surprising delight to traverse. It has many pages to help you create an account, write extensions properly, and much, much more. MediaWiki did exactly what a wiki should do: it taught me. And more importantly, it taught me useful things, the most important of which is how to edit a wiki page. My previous attempts at editing wiki pages did more harm than good, but with my improved knowledge of the syntax, I can actually help contribute to the numerous wikis I, and many others, frequent every day.

I also liked’s forum, called “Project:Support desk“, although I had trouble finding it at first. It is as simple as the press of a button to start your new thread. From the looks of other threads, there are many users that are glad to help, and questions are usually answered (or at least attempted to be) in a very short period. Your questions will not go unnoticed. It is a fantastic forum, and although some of the questions might seem advanced for newcomers, just ask any question you might have about MediaWiki, and I’m sure it will get answered.

Ashwin Bhumbla
2013 Google Code-in student

  1. Editor’s note: The Wikitech wiki is actually for documenting Wikimedia’s technical operations and infrastructure, i.e. information on the servers, network, and Wikimedia Labs.

Read in this series:

Seeing through the eyes of new technical contributors

Do you remember the first time you contributed to Wikipedia or one of its sister projects?

As we become more involved in the Wikimedia community, and more knowledgeable about its culture, tools and policies, we tend to forget how and why we came to join that community, and what hurdles we had to overcome to get where we are now.

We tend to forget the frustrations we encountered while going through the documentation, or the confusion we experienced when faced with complicated tools and arcane processes. Once we’ve gotten used to them, we have little incentive to improve the system.

It’s incredibly valuable for a community to be reminded of that newcomer experience. Not only does it help identify pain points of newcomers that the community can reduce, but it can also be an eye-opening experience that challenges long-established anti-patterns. This is true whether we’re talking about new editors on a Wikimedia wiki, or new tech contributors who want to improve the software and technical infrastructure.

One goal of the Engineering community team at the Wikimedia Foundation is to facilitate the integration of new tech contributors. We do this through a variety of activities, which include for instance the organization and coordination of mentoring programs, like Google Summer of Code, the Outreach Program for Women and Google Code-in.

Another way to make the first steps of new tech contributors easier is to improve the portals, to make sure the documentation stays up-to-date and to identify where newcomers stumble, get blocked or rage quit.

In order to capture that newcomer experience and use it to improve our pipeline, we’ve asked Google Code-in students to write “discovery reports”, i.e. short candid essays outlining what surprised them during their first steps, whether good or bad.

Their mission, which 13 students chose to accept and completed successfully, was:

  • to explore MediaWiki’s and Wikimedia’s technical world;
  • to write down their feelings, impressions, frustrations, pleasant and unpleasant surprises with the code, community and tools as they explored;
  • to organize their notes into a short candid essay;
  • to create an account on and post their essay on their user page.

Over the next few days, I’ll be posting a selection of their essays here, slightly edited for publication. We’ve already learned a lot, and I think there’s value in showing them to a wider audience.

If you’re a newcomer to the MediaWiki and Wikimedia technical community, I encourage you to write a discovery report as well. Each contributor’s perspective is different, and each candid essay sheds light on new areas of our community in need of improvement.

Your exploration can focus on a specific area (for instance: setting up a development environment, finding documentation about a specific part of the software, translating the software, etc.) or be more general. Make sure to drop me a note by e-mail or talk page so your essay doesn’t get lost in an obscure corner of the wiki.

If you’re a more experienced member of our community, I hope those discovery reports will be useful to you, and will help us make it easier to welcome and guide new tech contributors.

Guillaume Paumier
Technical communications manager, Wikimedia Foundation

Read in this series:

Wikimedia engineering report, February 2014

Major news in February include:

  • a call for volunteers to test the upcoming multimedia viewer;
  • improvements to VisualEditor’s media and template editors;
  • the launch of the Flow discussion system on two pilot talk pages on the English Wikipedia;
  • the launch of guided tours to 31 more language versions of Wikipedia, including all of the top 10 projects by number of page views;
  • improvements to the tools and process used to deploy code to Wikimedia production sites;
  • the release of the first archive of the entire English Wikipedia with thumbnails, for offline use.

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.

Wikimedia engineering report, January 2014

Major news in January include:

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.

Wikimedia engineering report, December 2013

Major news in December include:

  • a retrospective on Language Engineering events, including the language summit in Pune, India;
  • the launch of a draft feature on the English Wikipedia, to provide a gentler start for Wikipedia articles.

Note: We’re also providing a shorter, simpler and translatable version of this report that does not assume specialized technical knowledge.