Elyssa Faison has been assigning Wikipedia projects in both undergraduate and graduate classes since 2015. She is an associate professor in the Department of History at the University of Oklahoma.

When I was first approached several years ago by the Assistant Director of the Office of Digital Learning at my university about assigning a Wikipedia project in my class, I was skeptical. I had never edited Wikipedia myself, had little understanding of how editing was done, and harbored doubts about the reliability of information on the platform. But our digital learning specialist, who himself had participated in numerous Wikipedia edit-a-thons, explained how content is monitored and how the demographics of Wikipedia editors can lead to the over- or under-representation of certain topics. 

Student editors in my classes on Japanese history, women’s history, and environmental history (and sometimes all three at once) could help add content in areas where it was most needed, he argued; and as their instructor, I could make sure that the content they were adding would be appropriate and properly sourced. What’s more, asking students to edit on Wikipedia would make them think in different ways, and would make them accountable to a broader public. Students who are accustomed to having a singular audience for their writing (their instructor), would now be producing work that could potentially be read by thousands.

Over the years I have developed a set of best practices for my own Wikipedia Project. You might choose to do things differently, but this is what has worked for me:

First, really commit. Set up your assignment to run for eight weeks or longer. For me, that’s half a semester. For some of you, it might be nearly an entire quarter. Students will need to understand the philosophy behind Wikipedia editing and some of the (not difficult) technical aspects of the platform. Then they will need to choose a topic, conduct research, write, edit their writing, and finally move their work to the main space of Wikipedia. Short-changing this process in terms of time can make all of you frustrated, as students struggle to keep up with the many new things they are learning about form, content, and technology. Dedicate a portion of class time each week—some weeks ten minutes will be sufficient; other weeks you might need more—to talk about the Wikipedia project and see if students have questions.

Second, use as many of the tools available on the Wiki Education Dashboard as possible. The Wiki Education team has put together an incredible dashboard that allows you to set up a timeline for the entire term that includes everything your students will need to move through the process step by step. The dashboard provides training materials for students and instructors and gives suggestions about assignments you might want to add to your syllabus as part of the project. You can choose which of them you want to use, but my own experience is that “more is more” in this particular case. Use these materials and assignments as the basis of the weekly discussions you have in class.

Third, once you have decided on assignments for your Wikipedia Project and have set up your timeline through the dashboard, take the time at the beginning of the term to integrate specific Wikipedia assignments and deadlines into whatever LMS you are already using for your course. While the Wiki Education Dashboard is fantastic, I learned by trial and error that students get frustrated and lose track of what they are supposed to do if the main syllabus and content of your course is on your LMS (Canvas, Blackboard, D2L), but you are counting on them independently knowing they also need to navigate over to their Wikipedia Project timeline on the dashboard. Something as simple as listing the specific Wikipedia assignment for the week in your main syllabus or weekly module system on your LMS signals to them that they need to move to the Wikipedia dashboard to get detailed instructions and complete that work.

Fourth, pre-select several stub articles appropriate for the topic of your course that students can choose to edit. Students in my Japanese history classes generally do not come into the course with enough background to be able to generate topics that might be good to work on. Give them a list of possibilities, and let them offer up something else for you to approve if they desire.

Fifth, take full advantage of the peer review process. (You can find guidance on this on the dashboard.) Reading each others’ work fine tunes students’ understanding of how to write a good Wikipedia article. They get to see examples of good or not-so-good use of sources, tone, and basic writing. And they learn from each other in ways they don’t always learn from us.

We all use Wikipedia. As it has become more robust over the years, it has turned into an indispensable resource to check facts and dates, or to get a quick overview of a topic. This is as true for faculty as it is for undergraduates, graduate students, and the general public. Over the years, students in my classes—undergraduate and graduate alike—have consistently commented on how the project has changed their own perceptions of Wikipedia. In the reflection papers they write after completing their articles, time and time again students leave the class saying things like “Wikipedia’s editing process was more structured than I had expected,” and “the information put on Wikipedia has to go through a lot more vetting than I had originally thought.”

In recent years, students in my classes have contributed significantly to articles related to Japanese women’s history and Japanese environmental history. They have engaged with other Wikipedians on the talk pages of the articles they are working on, and they have seen that their work really is getting an audience. They get to experience how the work of historians is important in a way that writing a term paper that only I will ever read could never teach them.

Image of Bizzell Library credit: ragesoss, CC BY-SA 2.0, via Wikimedia Commons

By Dr Sara Thomas, Scotland Programme Coordinator

As Wikimedia UK, we work to support language communities living in, or connected to the UK. This translates to a range of projects, including Scots Wikipedia. 

Up until recently, there were only a relatively small number of regular, active editors of sco.wiki. However, as of the end of August, that has most definitely changed. And that’s the best thing that we could have hoped for. I really hope that these new editors will feel motivated to stick around, because their long-term support will would be transformational for the Scots Wiki, and hopefully will have benefits for the wider Scots language community too.

With all the press coverage, a certain amount of immediate interest was inevitable. And the community has worked hard to increase their capacity to help deal with this; nominating and onboarding new Scots-speaking admins, improving on-wiki tools, organising review of articles, discussing spelling and dialect, deflecting vandalism, writing a new notability policy, deleting spam.

We’ve been heartened by the energy and proactive attitude of the existing Scots wiki community in dealing with the increased attention and participation in their project. At the same time, it was disappointing to see some of that attention fail to assume good faith on the part of the editor upon whom attention fell, and to engage in personal criticism. That’s not a behaviour we would support, and what we want to focus on here is the positive impact of the story on Scots wiki. 

With any minority language Wikipedia, community building is incredibly important; one of the ways this happens is through events like the Celtic Knot conference which Wikimedia UK have organised since 2017. Calls for content to be parachuted into the Wiki are ultimately not the most helpful, not least because a Wiki relies on its community; it needs the ongoing support and oversight of that community to survive. It needs those volunteers who look out for vandalism, who fix spelling mistakes, who create new articles, who review articles, who work on tech infrastructure – all of those kinds of things which it’s easy to take for granted if you spend most of your time on en:wiki. If you want paid editing, and an encyclopedia which remains fixed in one point in time, there are options for that. But that is not Wikipedia. 

The relationship between a chapter and a language Wikipedia is one of support, not of dictatorship. So as Scotland Programme Coordinator for Wikimedia UK what I’ve been working on for the last few months is seeing how I can support, and help to grow that community. 

In practice, what that’s meant is a whole load of activity if not behind the scenes, then in the wings. User:Cobra3000 set up a two-day editathon at the end of August, for which I ran online training sessions (we’ve been doing a lot of that recently) using the Wikimedia UK Zoom and Eventbrite accounts; set up a Dashboard to track activity; helped to set up an on-wiki event page, and I created and uploaded some sco.wiki specific how-to videos to Commons, which went on the event page, was used for training, and in the off-wiki locations where activity was being organised – Cobra3000’s Scots Language Discord server, and the new Scots Wikipedia Editors Facebook group, which is now at over 100 members. I’ve been active in both of the latter, answering questions, promoting the training, and answering wiki-specific questions where possible. For the editathon, we also were sure to include a range of activities for non- or lower-proficiency Scots speakers, of whom there were many who were interested in helping out. Dr Michael Dempster of the Scots Language Centre has been very involved, including making an 8 hour introduction to Scots course available for free on YouTube. The editathon produced some quite incredible stats; they include high-volume AWB tasks, but even so, I was excited to see the enthusiasm and care that the community has for the Wiki. 

We’ve also been talking to the Scots Language Centre about how we might engage the wider Scots community with Wikimedia in the future, and this will hopefully build on some existing projects which had to be shelved due to COVID. 

The second editathon was held at the end of September, focussing on places, and we hope that these editathons can become a regular event. Now that we’ve done with the initial firefighting period, it’s time to dig in for the long term. 

If you’d like to find out more about community building through events, you can get involved here, or to see more about our Scottish activities, you can browse the blog tag.

This fall, we’re celebrating the 10th anniversary of the Wikipedia Student Program with a series of blog posts telling the story of the program in the United States and Canada.

In 2018, Wiki Education launched a three year strategic plan whose three pillars are equity, quality, and reach. Equity, however, has long been one of the defining forces behind Wiki Education and the Wikipedia Student Program since its inception in 2010. Wikipedia aims to represent the sum total of human knowledge, but despite its more than 6 million articles, it still has a long way to go. This is especially true when it comes to topics that deal with historically underrepresented populations, such as women and minorities, as well as more academic subjects. With their access to information, often behind paywalls for the population at large, and with their instructors, experts in their subject-matter areas, to guide them, the program quickly realized that students can play a critical role in making Wikipedia a more equitable space.

Knowledge equity can be an elusive concept and difficult to define. At its core, though, lies two key pillars: knowledge should be accessible both in its creation as well as its dissemination. It means that knowledge should be accurate, representative, and inclusive to those who seek to create it as well as those who seek it out. While knowledge equity has been at the core of our programs since the beginning, it’s taken on new meaning and urgency in recent years with the rise of fake news and the ease with which misinformation is so readily spread.

Equity through participation

Knowledge is only as equitable as its creators and disseminators. Filling in content gaps and correcting the historical record is a critical part of knowledge equity, but who creates knowledge matters. This is especially true on Wikipedia, a site run by a volunteer base composed overwhelmingly of people who identify as white and male. We’ve known since the outset of the Student Program that roughly 60% of the students we support are women. This is representative of college campuses nationwide. Based on recent survey results, we also know that about 17% of our students identify as Asian, 13% as Hispanic/Latinx, and about 6% as African-American. Additionally, 45% of the students in our program speak another language other than English, and roughly 8% identify as having a disability.

While the makeup of the students in our program is fairly representative of college campuses nationwide, it deviates quite dramatically from Wikipedia’s active editing community. We also know that 19% of all new active editors to English Wikipedia come from the Student Program. While Wikipedia strives to promote a neutral point of view in all of its content, our students bring a diversity of perspectives and experiences that ultimately make Wikipedia a more inclusive, accessible, and equitable place. Whether it’s writing about a language they speak, the town they come from, or another topic near and dear to their heart, our students bring new voices to the Wikipedia editing community.

In recent years, we’ve also begun to collect demographic data on the instructors who participate in our program. Where our students are consistent with college campuses more broadly, our instructors deviate dramatically from academia as well as the Wikipedia editing community. More than 60% of the instructors who participate in our program are women, a number that is far higher than the 30% that make up academia. While most of our instructors do not contribute to Wikipedia directly, they are nevertheless important members of the Wikipedia community. They are using their expertise to guide their students and ensure that their areas of subject-matter expertise are accurately represented on Wikipedia. They too influence Wikipedia’s trajectory and diversify its base of knowledge creators. Whether these professors are focused on Women’s and Gender Studies, improving biographies of women, or plant biology, they are making Wikipedia more equitable.

Not content with content gaps

Whether they come to the Wikipedia assignment with knowledge equity in mind or not, all of our instructors and students participate in making Wikipedia more equitable. They do this through their very participation, but also in the content they produce. A content gap is just that, a gap in knowledge, but not all content gaps are created equally. Wikipedia has notable content gaps in subjects related to women, minorities, and other historically underrepresented populations. It also has significant gaps in more academic and obscure topics. The reasons for these gaps are complex. They arise in part due to who edits Wikipedia, but it also is the result of the fact that these subjects are often poorly sourced in the written record. To a large degree, Wikipedia reflects broader societal biases. Reflection, though, need not mean reinforcement. While this is often the case, Wikipedia can be a powerful tool for correcting those inequities in content. We know that Wikipedia is not a one way street. Information flows both into and out of Wikipedia. It is not simply a repository of information, but an agent of knowledge creation and dissemination.

Most notable among these content gaps is Wikipedia’s gender gap. Despite the fervent efforts of WikiProject: Women in Red, only slightly more than 18% of Wikipedia’s biographies are of women. Women are all too often written about as someone else’s wife or mother rather than for their own achievements. The same is true for other historically underrepresented populations.

To help scale our work in filling in these content gaps, we’ve formed several partnerships with academic organizations over the years. In 2014, we began our important work with the National Women’s Studies Association (NWSA) to tackle Wikipedia’s gender gap. In that time, we’ve worked with 405 courses whose roughly 8,600 students have added more than 6 million words on Wikipedia in the field of Women’s and Gender Studies. Because of our students, the world now has access to information ranging from Mental disorders and gender to Chanda Prescod-Weinstein, American cosmologist and activist.

Equity is as much about producing content as it is about having access to that content. It’s not just about correcting the record so that a female scientist gets proper recognition for her contribution to a field, but that other women seeking to establish themselves in that same field have a role model to which they can turn. Six million words is certainly a lot, but we’ve hardly scratched the surface when it comes to filling in these critical content gaps.

Equity as a skill

While knowledge equity has been a driving force in the Student Program since its inception, we’ve come to realize in recent years that tackling issues of equity is a skill to be learned, honed, and practiced. We know that there is a steep learning curve when it comes to contributing to Wikipedia. To shepherd our students through this sometimes complex and confusing process, we’ve developed a host of training materials to ensure that students can successfully make those first edits. But just as important as it is to learn how to cite work or add media is how to identify equity gaps on Wikipedia and remedy them.

Over the past year we’ve made a series of updates to our resources so that students and instructors are thinking about equity at every step in the process of learning how to contribute to Wikipedia. In fact, it’s our goal to make editing Wikipedia and tackling knowledge equity one and the same. Whether its asking students to think about how to critically evaluate a Wikipedia article, whether the sources they’re using come from a diverse array of authors, or whether their classmates addressed knowledge equity in their peer review, we want to make sure that students are able to identify bias and ultimately to correct it where possible.

We encourage students to think more deeply about Wikipedia through a series of discussion prompts, covering topics ranging from sources and plagiarism to content gaps to thinking about Wikipedia broadly speaking.

It’s long been our goal to help our students develop digital literacy skills, to enable them to discern reliable information from unreliable so that they can become full digital citizens of our modern media landscape. It’s now our twin goal that our students are also able to identify bias and knowledge inequities both on and off of Wikipedia and to correct those inequities where possible. It’s a skill that is undeniably difficult to measure and assess, but we’re highly encouraged by the fact that over 60% of instructors believe that the Wikipedia assignment achieves this very goal.

It’s no surprise that many of our instructors view the Wikipedia assignment as an act of social action. As one instructor put it: “It provides an opportunity for those who have access to reliable information to share it with those who do not have access. It also inspires people who are used to only writing transactionally to shift focus and write to support the common good as part of a community of writers.”

We know that our students will continue to play a critical role in making Wikipedia a more equitable space because knowledge equity does not have a finite finish line. It’s an ongoing endeavor of which we are truly proud to be apart.

I wanted to make an educational typeface with writing directions in each glyphs. Something like this: But considering the effort it takes I was bit confused whether it is really necessary to have a typeface or just images like this will suffice. Recently, I read about SVG path animations and I thought animating the path inside each letters will be more helpful than static image with drawing directions.

By Giuseppe Lavagetto, Principal Site Reliability Engineer, The Wikimedia Foundation

The challenges of running PHP applications at a large scale

PHP is a very successful language, if not a loved one. It powers many of the most visited websites in the world, including our wikis. MediaWiki, the software that runs our sites, and 100,000s of wikis worldwide, is written in PHP.

The reason for PHP’s success can be traced back, according to Keith Adams, to three salient characteristics of the language—which are really characteristics of its runtime:

• Scoping: all state is local to a request, and by default, all requests share nothing with each other. Every resource that is allocated during a request gets thrown away at its end. There are mechanisms like APCu that allows the use of a shared memory segment, but the complexity is hidden from the developer.
• Concurrency: given each request is isolated, concurrency is free in PHP. You can respond to multiple requests in parallel without any sort of coordination between threads.
• Development workflow: since there’s no persistent state and no compilation step, you can quickly check your work while developing a web application by editing the code and immediately refreshing the page, without restarting anything.

The scoping rules are both a blessing and a curse for a high traffic website. Not being able to share anything between requests means you can’t have things like connection pools so that whenever PHP needs to connect to any external service (be it a datastore or another HTTP application), it needs to initiate a new upstream connection.

Sometimes the cost of establishing a new connection is so high that it has a significant impact on the performance of the application. This problem is common among large-scale websites, so for example HHVM, the PHP/Hack virtual machine created by Facebook, implements connection pooling for curl requests. As longtime users of HHVM, the built-in connection pooling was of utmost importance to us in mitigating the performance penalty when calling services via TLS over a network link with non-negligible latency—say another datacenter.  

Given that HHVM has moved away from 100% compatibility with PHP, last year we migrated our MediaWiki installation from HHVM to PHP 7. The migration was a success, but we encountered a number of differences that had significant impacts, both positive and negative. Specifically, PHP 7 lacks facilities to create HTTP connection pools for its curl extension.

We measured the latency impact of having to establish a new connection for every encrypted request across datacenters to be in the order of 75 milliseconds—which is what we expected given establishing a TLS connection requires  2 additional round-trips compared to a non-encrypted TCP connection.

A service to manage outgoing HTTP requests

Enter Envoy, our TLS terminator of choice. Envoy is much more than just a reverse proxy: it’s designed to be a service middleware. It’s intended to work as a connective tissue between services in modern infrastructural stacks (aka, “cloud-native” stacks). Since Envoy has efficient built-in support for connection pooling, it seemed that introducing it as a proxy not just for incoming requests to provide encryption, but also for outgoing requests, could help us close the performance gap, by cutting out the TLS connection overhead from each request.

The impact of persistent connections: a simple test

First, we wanted to measure performance with a simple benchmark—fetch the banner page of ElasticSearch (the software that powers the Wikipedia search box), a small JSON document, via a PHP script and measure the number of requests per second sustained over a fixed concurrency while varying the way we connected to Elasticsearch.

The results were unequivocal. While using encryption caused a severe performance degradation, introducing Envoy as a local sidecar, called via HTTP to mediate HTTPS requests to the ElasticSearch cluster produced a 46% throughput gain compared to unencrypted direct connection, and a 120% gain compared to direct connections using HTTPS. This may be counterintuitive: adding an intermediary process made the outbound connection much faster—even compared to the baseline with no TLS at all!—because the local Envoy was able to reuse its sessions with remote ElasticSearch hosts.

These results—while not fully representative of real-world situations—looked extremely promising: we had a path forward for mitigating the performance penalty of encryption over higher latency networks.

The effect of using Envoy on our applications

So, we proceeded with the second phase of our transition, using Envoy as a proxy to manage HTTP requests that MediaWiki performs to other services, prioritizing services that were already called via TLS. One such service is sessionstore, a REST service that stores user sessions for MediaWiki; this service now powers all of our wikis, and receives around 20 thousand requests per second. At the time of the transition, it was serving only a portion of the wikis, and thus racking up around 4500 req/s. We expected that not having to establish 4500 TLS connections would save us some network traffic and some CPU churn for the service even if the network latency was small. The actual effect we observed was still surprising: the CPU usage for the application went from 2.5 CPU cores to circa 0.8 CPU cores as soon as we deployed the configuration change.

Basically, 70% of the resources used by the service were spent to instantiate a new TLS connection for each request! We also expected to see a reduction in the network traffic, as not only the whole TLS handshake procedure would happen for a fraction of the requests, but the service didn’t need to send out its TLS certificate 4500 times per second. Even if the certificate is just 1.67 kb, sending it 4500 times per second means we’re sending about 7 MB/s of data just for that. And indeed, the effect was quite impressive.

As you can see, the reduction in bandwidth happens for both received and transmitted bytes.

While these results are remarkable, they are of little interest to our users if their experience does not improve as well. Fortunately, we did expect this change to have an effect on the performance of both the service (as it could answer requests without the TLS overhead, which is not negligible even over a local network where latencies are a fraction of a millisecond) and of MediaWiki itself. The net result on the service can be seen by a graph of its responses, stacked by latency bucket:

The number of responses taking less than 1 millisecond to complete (in green) doubled and the long tail of responses over 5 milliseconds (in red and violet) almost disappeared. 

As for the effect on MediaWiki, the number of requests that returned in less than 100 milliseconds rose by 12%. This is a significant gain, more so if we take into account that the switch only affected a portion of our traffic.

The performance increase is so notable that it allowed us to make MediaWiki call all services with encryption, without risking the severe degradations of service performance that we had experienced after the migration from HHVM to PHP any time we had MediaWiki call services cross-datacenter.

Conclusions

Introducing a service proxy like Envoy between a PHP application and other services allowed us to create connection pools and thus reduce the latency and cost of calls between the application and other services. As shown, the gains we obtained were large enough to be noticeable in the overall latency of the application.

We had further reasons for choosing Envoy, —the ability to introduce rate-limiting, circuit-breaking, and observability to a microservice architecture in a consistent manner. We’ll take a deeper look at these in another post.

Our experience shows that anyone running PHP applications in a microservices architecture can obtain immediate performance and stability benefits by adding an efficient connection pooling proxy between the application and other services. In particular, if you run your applications in the cloud over multiple availability zones, or from multiple datacenters as we do, the performance improvements are probably going to be noticeable to your end-users. 

About this post

Featured image credit: JNEM detail, Daniel Schwen, CC BY-SA 4.0

https://spell.toolforge.org/ is a webservice providing spellcheck web API for 90 languages. I wrote this service hoping that it can be potentially integrated to wikipedia editor to help contributors. The spellchecker backend is hunspell for majority of the languages. It can also proxy similar webservices to provide a single interface. For Malayalam language it uses such an external web API. This Express based nodejs service interfaces to hunspell using nodehun. API GET spellcheck/:language/:word: Check the word in the given language for spelling mistakes.

docs.thottingal.in is my personal knowledge space I try to document and share everything I know about this world in form of an online GitBook hosted on GitHub. What is a digital garden? In basic terms, it is a different format for written content on the web. It’s about moving away from blog posts ordered by dates and categories, into more of an interlinked web of notes. Blog posts are articles at a point in time, while here it is living document.

13/10/2020-19/10/2020

Mapping

• Robert Delmenico suggested, on the tagging mailing list, replacing man_made=* with human_made=*. Many doubted the value of the proposal. Such suggestions are repeated every few years (February 2012, March 2017).
• Following a report > by n-tv, which reveals the unexpectedly high number of trees in the Sahara and Sahel, there was a discussion > about what forest density and size is actually needed to match the established tagging for forest and woodland in OSM.
• Mueschel’s proposal for the new tags electric_bicycle and speed_pedelec has been approved.
• User bkil proposed the tag audible=* for ‘objects generating audible cues’. Voting is underway until the end of October.
• Robhubi published a blog post > about the distinction between pavements and footpaths in Austria. The differentiation has an impact on the vehicles permitted to use them.

Community

• Jean-Marc Liotier published an article ‘Measuring data quality or why are we even Openstreetmapping anyway’ in which he doesn’t define any quality metrics but reframes the problem instead.
• LCCWG, the ‘Local Chapters and Communities Working Group’, invites you to join the working group.
• The Mapillary team is seeking editors using JOSM to interview about their workflows, whether or not they include use of the Mapillary plugin for JOSM. Interested users should reach out to osm@mapillary.com.
• Want to receive a postcard? Hungry for a connection with a fellow OSMer? Try OSMCards: a service to send or request postcards from many OSM contributors all over the world. See the talk recording from the SotM 2020 to see why it was made and how it works.
• Steve Coast is upset that he was denied a Foundation ‘free membership’. Active Contributor Memberships were introduced by the Foundation to encourage more active community members to join the OSMF. People can demonstrate their active contribution by having mapped on 42 or more days, or explaining how else they have contributed to OpenStreetMap, over the past year.

Imports

• Ben Discoe updated his TIGER node/way burndown chart and concludes that, if progress continues at the same rate, in about 29 years each imported TIGER node will have been touched and the community will need more than 9 years ‘before each path is hopefully aligned and cleaned up’.

Local chapter news

• Anita Graser was honoured with the 2020 Sol Katz Award, presented on 10 September 2020, during the virtual OSGeo Annual General Meeting. She is best known for being involved in QGIS, which is one of the most successful OSGeo projects. Read more about Anita Graser in her blog.
• OSM RDC’s application for membership as a local chapter of OSM in the Democratic Republic of the Congo is online.
• Thierry Hancart is Mapper of the Month of the Belgian local chapter.

Events

• The OpenStreetMap conference US Connect 2020 will take place online next weekend. The programme has been announced: three days of talks, workshops, birds of a feather sessions, mapathons, and opportunities to connect with fellow OpenStreetMap enthusiasts!
• Geoweek and Weekend 2020 > will be held as a pre-event for mapping and hacking to make SotM Japan 2020 > and FOSS4G 2020 Japan Online > even more exciting. Registration is here .
• The OSGeo Day videos of AGIT 2020 are now available online > .

Humanitarian OSM

• The UN Mappers (‘Mapping the #world and serving humanity’) have set up a task on HOT’s Tasking Manager to map roads, waterways, and villages in Somalia.
• Students of EuYoutH_OSM met online for a joint mapping exercise using the Task Manager of FrancophoneLibre.
• Russ Deffner has called on the OSM community to take action against COVID-19, by contributing to one of HOT’s projects either on their Tasking Manager or Mapswipe.
• Five OSM communities, spread across the Philippines, Turkey, Uganda, Kenya, and Zambia, have received Facebook Community Impact Microgrants to support community engagement and training.
• Long-time contributor Russ Deffner celebrates his 10-year anniversary with a diary entry where he summarises the past year and shares his aspirations for the next one.
• CartONG has announced it has opened registration for the 2020 GeOnG Forum. The forum will be focused on how information management technology and practices can truly be human-centred, integrating the (different) rights of people and communities in their full diversity.

Maps

• The Ministry of Public Works and Transport of Costa Rica has published, over an OSM base map, a map of the National Road Network with roads classified as primary, secondary, tertiary, or cross streets.
• The CGN Spotter Guide makes > plane spotting much easier around Cologne Airport (CGN) and some other places.

Software

• Still a fan of the Potlatch 2 aesthetic? JOSM includes a conversion of the map style. Guillaume Rischard has vectorised it. The modernised version can be included in the Map Paint Styles preferences.

Programming

• The new openrouteservice map client (VueJS) development is in the final phase and now has a feature that allows routes, isochrones, and other features from openrouteservice (ORS) to be integrated into other websites (with the embedding code available via a share button). This allows webmasters and editors to embed those geographic features easily into their websites using the new ORS client.

Did you know …

• [1] … there is a tool to check your opening_hours tagging?

Other “geo” things

• Wikimedia CH is currently running a four-language writing competition for articles on Swiss castles and palaces. The purely virtual event runs until the end of November. Every Monday an online meeting is held from 7 to 8 PM, as an informal BigBlueButton session, in which everyone speaks their native language or English.
• Germany introduced > their Experimental Space Surveillance and Tracking Radar (Gestra), designed to track space debris. It consists of two units, each the size of a shipping container. Entry into service is planned for the beginning of 2021.
• Apple announced version 1.0.0 of their ‘Indoor Mapping Data Format’. As a commentator said ‘YAPF: Yet Another Proprietary Format’.
• The Sounds of the Forest collected sounds from forests and woodlands across the world. Supported by the PRS Foundation’s Open Fund for Organisations, music will be created from the collected data and premiered at next year’s Timber Festival on 2 to 4 July 2021.

Upcoming Events

Where	What	When	Country
Cobb Virtual Academy	Wikidata+OSM: Its use cases	2020-10-25
Rennes	Atelier découverte OSM / Wikipédia / Wikidata [1]	2020-10-25
Bremen	Bremer Stammtisch	2020-10-26
Arlon	(cancelled – annulé) Réunion des contributeurs OpenStreetMap	2020-10-26
Salt Lake City / Virtual	OpenStreetMap Utah Map Night	2020-10-27
Düsseldorf	Düsseldorfer OSM-Stammtisch	2020-10-28
Salt Lake City / Virtual	OpenStreetMap Utah Map Night	2020-10-29
London	Missing Maps London Mapathon	2020-11-03
Stuttgart	Stuttgarter Stammtisch (online)	2020-11-04
Dresden	Dresdner OSM-Stammtisch	2020-11-05
Online	State of the Map Japan 2020 Online	2020-11-07
Taipei	OSM x Wikidata #22	2020-11-09
Salt Lake City / Virtual	OpenStreetMap Utah Map Night	2020-11-10
Munich	Münchner Stammtisch	2020-11-11
Zurich	123. OSM Meetup Zurich	2020-11-11
Berlin	149. Berlin-Brandenburg Stammtisch (Online)	2020-11-12
Online	2020 Pista ng Mapa	2020-11-13-2020-11-27
Online	FOSS4G SotM Oceania 2020	2020-11-20

Note: If you like to see your event here, please put it into the calendar. Only data which is there, will appear in weeklyOSM. Please check your event in our public calendar preview and correct it, where appropriate.

This weeklyOSM was produced by Climate_Ben, MatthiasMatthias, MichaelFS, Nordpfeil, PierZen, Polyglot, Rogehm, TheSwavu, YoViajo, derFred, richter_fn, Can.

I added this template {{PositionHolderHistory|id=Q**}} to all the items for an office in my African politicians project.  You find the template on the talk page and like the Listeria lists, they show past and present office holders.

I still prefer my method of including the "red links" in Wikidata but it is a wiki and there is so much more to do.. What I started to do with office holders from Togo is that for those I will not link to predecessors and successors, I will at least show the dates they were in office. 

It looks much better in Listeria too. 

Thanks, GerardM

The test corpus for Malayalam Morphological analysis has many foreign words. They are either written in a non-Malayalam script or written in Malayalam. For example, “ഇലക്ട്രിസിറ്റി”, “ഡോക്സ്”, “ഇന്റർമീഡിയറ്റ്”, “അബ്സ്ട്രാക്റ്റ്”, “ഇല്ലസ്ടേഷൻ”, “ഇല്ലിറ്ററേറ്റ്”, “റെക്കോർഡ്”, “procrastination”, “唐宸禹” - These are all foreign words and it is useless to analyse them using mlmorph. Since mlmorph works based on a root word lexicon, it is practically impossible to have them in lexicon. So there should be a way to identify the words easily and tag them as FW - Foreign word Part of speech.

How’d we do in our strive for operational excellence last month? Read on to find out!

📈 Incidents

5 documented incidents. [1] Historically, that's right on average for the time of year. [3]

For more about recent incidents see Incident documentation on Wikitech, or Preventive measures in Phabricator.

📊 Trends

Month-over-month plots based on spreadsheet data. [5]

📖 Outstanding errors

Take a look at the workboard and look for tasks that could use your help.
→ https://phabricator.wikimedia.org/tag/wikimedia-production-error/

Summary over recent months:

• ⚠️ July 2019 (4 of 18 tasks left): no change.
• ⚠️ August 2019 (1 of 14 tasks left): no change.
• ⚠️ September 2019 (3 of 12 tasks left): no change.
• ⚠️ October 2019 (6 of 12 tasks left), no change.
• November (3 of 5 tasks left): no change.
• December (3 of 9 tasks left), no change.
• January 2020 (4 of 7 tasks left), One task closed.
• February (2 of 7 tasks left), no change.
• March (2 of 2 tasks left), no change.
• April (10 of 14 tasks left): no change.
• May (7 of 14 tasks left): no change.
• June (7 of 14 tasks left): Three tasks closed.
• July 2020 (10 of 24 new tasks): Three tasks closed.
• August 2020 (31 of 53 new tasks): Six tasks closed.
• September 2020: 17 of 33 new tasks survived the month of September and remain open today.

Previously, we had 106 unresolved production errors from the recent months up to August. Since then, 13 of those were closed. But, the 18 errors surviving September raise our recent tally to 110.

The workboard overall (including errors from 2019 and earlier) holds 343 open tasks in total, an increase of +47 compared to the 296 total on Sept 23rd.

🎉 Thanks!

Thank you to everyone else who helped by reporting, investigating, or resolving problems in Wikimedia production. Thanks!

Until next time,

– Timo Tijhof

🕵️‍♀️ Holmes: “So, she pulled five bullets out of you?”

     Shinwell: ”That's right.”
     Holmes: “I too have been shot five times. But, uh..., separate occasions.”
     Shinwell: “That's... great.”

Footnotes:

[1] Incidents. – wikitech.wikimedia.org/wiki/Incident_documentation
[2] Open tasks. – phabricator.wikimedia.org/maniphest/query…
[3] Wikimedia incident stats. – codepen.io/Krinkle/full/wbYMZK
[4] Month-over-month plots. – docs.google.com/spreadsheets/d/1tRC…

This is a new version of a post that was originally published in 2015. Much of it is the same, but there are several updates that justified publishing a whole a new version.

Introduction

As you probably already know, Wikipedia is a website. A website has two components: the content and the user interface. The content of Wikipedia is the articles, as well as various discussion and help pages. The user interface is the menus around the articles and the various screens that let editors edit the articles and communicate to each other.

Another thing that you probably already know is that Wikipedia is massively multilingual, so both the content and the user interface must be translated.

Translation of articles is a topic for another post. This post is about getting all the user interface translated to your language, and doing it as quickly, easily, and efficiently as possible.

The most important piece of software that powers Wikipedia and its sister projects is called MediaWiki. As of today, there are more than 3,800 messages to translate in MediaWiki, and the number grows frequently. “Messages” in the MediaWiki jargon are strings that are shown in the user interface. Every message can and should be translated.

In addition to core MediaWiki, Wikipedia also uses many MediaWiki extensions. Some of them are very important because they are frequently seen by a lot of readers and editors. For example, these are extensions for displaying citations and mathematical formulas, uploading files, receiving notifications, mobile browsing, different editing environments, etc. There are more than 5,000 messages to translate in the main extensions, and over 18,000 messages to translate if you want to have all the extensions translated, including the most technical ones. There are also the Wikipedia mobile apps and additional tools for making automated edits (bots) and monitoring vandalism, with several hundreds of messages each.

Translating all of it probably sounds like an impossibly enormous job. It indeed takes time and effort, but the good news are that there are languages into which all of this was translated completely, and it can also be completely translated into yours. You can do it. In this post I’ll show you how.

A personal story

In early 2011 I completed the translation of all the messages that are needed for Wikipedia and projects related to it into Hebrew. All. The total, complete, no-excuses, premium Wikipedia experience, in Hebrew. Every single part of the MediaWiki software, extensions and additional tools was translated to Hebrew. Since then, if you can read Hebrew, you don’t need to know a single English word to use it.

I didn’t do it alone, of course. There were plenty of other people who did this before I joined the effort, and plenty of others who helped along the way: Rotem Dan, Ofra Hod, Yaron Shahrabani, Rotem Liss, Or Shapiro, Shani Evenshtein, Dagesh Hazak, Guycn2 and Inkbug (I don’t know the real names of the last three), and many others. But back then in 2011 it was I who made a conscious effort to get to 100%. It took me quite a few weeks, but I made it.

However, the software that powers Wikipedia changes every single day. So the day after the translations statistics got to 100%, they went down to 99%, because new messages to translate were added. But there were just a few of them, and it took me only a few minutes to translate them and get back to 100%.

I’ve been doing this almost every day since then, keeping Hebrew at 100%. Sometimes it slips because I am traveling or because I am ill. It slipped for quite a few months in 2014 because my first child was born and a lot of new messages happened to be added at about the same time, but Hebrew got back to 100%. It happened again in 2018 for the same happy reason, and went back to 100% after a few months. And I keep doing this.

With the sincere hope that this will be useful for helping you translate the software that powers Wikipedia completely to your language, let me tell you how.

Preparation

First, let’s do some work to set you up.

If you haven’t already, create a translatewiki.net account at the translatewiki.net main page. First, select the languages you know by clicking the “Choose another language” button (if the language into which you want to translate doesn’t appear in the list, choose some other language you know, or contact me). After selecting your language, enter your account details. This account is separate from your Wikipedia account, so if you already have a Wikipedia account, you need to create a new one. It may be a good idea to give it the same username.

After creating the account you have to make several test translations to get full translator permissions. This may take a few hours. Everybody except vandals and spammers gets full translator permissions, so if for some reason you aren’t getting them or if it appears to take too much time, please contact me.

Make sure you know your ISO 639 language code. You can easily find it on Wikipedia.

Go to your preferences, to the Editing tab, and add languages that you know to Assistant languages. For example, if you speak one of the native languages of South America like Aymara (ay) or Quechua (qu), then you probably also know Spanish (es) or Portuguese (pt), and if you speak one of the languages of Indonesia like Javanese (jv) or Balinese (ban), then you probably also know Indonesian (id). When available, translations to these languages will be shown in addition to English.

Familiarize yourself with the Support page and with the general localization guidelines for MediaWiki.

Add yourself to the portal for your language. The page name is Portal:Xyz, where Xyz is your language code.

Priorities, part 1

The translatewiki.net website hosts many projects to translate beyond stuff related to Wikipedia. It hosts such respectable Free Software projects as OpenStreetMap, Etherpad, MathJax, Blockly, and others. Also, not all the MediaWiki extensions are used on Wikimedia projects. There are plenty of extensions, with thousands of translatable messages, that are not used by Wikimedia, but only on other sites, but they use translatewiki.net as the platform for translation of their user interface.

It would be nice to translate all of it, but because I don’t have time for that, I have to prioritize.

On my translatewiki.net user page I have a list of direct links to the translation interface of the projects that are the most important:

• Core MediaWiki: the heart of it all
• Extensions used by Wikimedia: the extensions on Wikipedia and related sites. This group is huge, and I prioritize it further; see below.
• MediaWiki Action Api: the documentation of the API functions, mostly interesting to developers who build tools around Wikimedia projects
• Wikipedia Android app
• Wikipedia iOS app
• Installer: MediaWiki’s installer, not used on Wikipedia because MediaWiki is already installed there, but useful for people who install their own instances of MediaWiki, in particular new developers
• Intuition: a set of tools, like edit counters, statistics collectors, etc.
• Pywikibot: a library for writing bots—scripts that make useful automatic edits to MediaWiki sites.

I usually don’t work on translating other projects unless all the above projects are 100% translated to Hebrew. I occasionally make an exception for OpenStreetMap or Etherpad, but only if there’s little to translate there and the untranslated MediaWiki-related projects are not very important.

Priorities, part 2

So how can you know what is important among more than 18,000 messages from the Wikimedia universe?

Start from MediaWiki most important messages. If your language is not at 100% in this list, it absolutely must be. This list is automatically created periodically by counting which 600 or so messages are actually shown most frequently to Wikipedia users. This list includes messages from MediaWiki core and a bunch of extensions, so when you’re done with it, you’ll see that the statistics for several groups improved by themselves.

Now, if the translation of MediaWiki core to your language is not yet at 18%, get it there. Why 18%? Because that’s the threshold for exporting your language to the source code. This is essential for making it possible to use your language in your Wikipedia (or Incubator). It will be quite easy to find short and simple messages to translate (of course, you still have to do it carefully and correctly).

Some technical notes

Have you read the general localization guide for Mediawiki? Read it again, and make sure you understand it. If you don’t, ask for help! The most important section, especially for new translators, is “Translation notes”.

A super-brief list of things that you should know:

• Many messages use symbols such as ==, ===, [[]], {{}}, *, #, and so on. This is wiki syntax, also known as “wikitext” or “wiki markup”. It is recommended to become familiar with some wiki syntax by editing a few pages on another wiki site, such as Wikipedia, before translating MediaWiki messages at translatewiki.
• “[[Special:Homepage]]” adds a link to the page “Special:Homepage”. “[[Special:Homepage|Homepage]]” adds a link to the page “Special:Homepage”, but it will be displayed as “Homepage”. In such cases, you are usually not supposed to translate the text before the | (pipe), but you should translate the text after it. For example, in Russian: “[[Special:Homepage|Домашняя страница]]”. When in doubt, check the documentation in the sidebar.
• $1, $2, $3: These are known as parameters, placeholders, or variables. They are replaced in run time, usually by numbers of names. Copy them as they are, and put them in the right place in the sentence, where it is right for your language. Always check the documentation in the sidebar to understand with what will they be replaced.
• If you see something like “$1 {{PLURAL:$1|page|pages}}” in a translatable message, this means that the word will be shown according to the value of the variable $1. Note that you must not change the “PLURAL:$1” part, but you must translate the “page|pages” part.
• If you see something else in curly brackets, it’s probably a “magic word”. Check the documentation to understand it. You usually don’t translate the thing in the beginning, such as {{SITENAME, {{GENDER, etc., but you sometimes need to translate things towards the end. See the localization guide for full documentation!

Learn to use the project selector at the top of the translation interface. Projects are also known as “Message groups”. For example, each extension is a message group, and some larger extension, such as Visual Editor, are further divided into several smaller message groups. Using the selector is very simple: Just click “All” next to “Message group”, and use the search box to find the component that you want to translate, such as “Visual Editor” or “Wikibase”. Clicking on a message group will load the untranslated messages for that group.

The “Extensions used by Wikimedia” group is divided into several more subgroups. The important one is “Extensions used by Wikimedia – Main”, which includes the most commonly used extensions. Other subgroups are:

• “Advanced”: extensions that are used only on some wikis, or are useful only to administrators and other advanced users. This should be the first subgroup you translate after you complete the “Main” subgroup.
• “Fundraising”: extensions used for collecting donations for the Wikimedia Foundation.
• “Legacy”: extensions that are still installed on Wikimedia sites, but are going to be removed. You can most likely skip this subgroup completely.
• “Media” includes advanced tools for media files curating and uploading, especially on Wikimedia Commons.
• “Technical”: this is mostly API documentation for various extensions, which is shown on the ApiHelp and ApiSandbox special pages. It is very useful for developers of gadgets, bots, and other software, but not necessary for other users. This group also includes several other very advanced extensions that are used only by a few people. You should translate these messages some day, but it’s OK to do it later.
• “Upcoming”: these are extensions that are not yet widely installed on Wikimedia sites, but are going to be installed soon. Translating them is a pretty good idea, because they are usually very new, and may include some confusing messages. The earlier you report these confusing messages to the developers, the better!
• “Wikivoyage”: extensions used only on Wikivoyage sites. Translate them if there is a Wikivoyage site in your language, or if you want to start one.

There is also a group called “EXIF Tags”. It’s an advanced part of core MediaWiki. It mostly includes advanced photography terminology, and it shows information about photographs on Wikimedia Commons. If you are not sure how to translate these messages, ask a professional photographer. In any case, it’s OK to do it later, after you completed more important components.

Getting things done, one by one

Once you have the most important MediaWiki messages 100% and at least 18% of MediaWiki core is translated to your language, where do you go next?

I have surprising advice.

You need to get everything to 100% eventually. There are several ways to get there. Your mileage may vary, but I’m going to suggest the way that worked for me: Complete the easiest piece that will get your language closer to 100%! For me this is an easy way to remove an item off my list and feel that I accomplished something.

But still, there are so many items at which you could start looking! So here’s my selection of components that are more user-visible and less technical. The list is ordered not by importance, but by the number of messages to translate (as of October 2020):

• Vector: the default skin for desktop and laptop computers
• Minerva Neue: the skin for mobile phones and tablets
• Babel: for displaying boxes on user pages with information about the languages that the user knows
• Discussion Tools: for making the use of talk pages easier
• Thanks: the extension for sending “thank you” messages to other editors
• Universal Language Selector: the extension that lets people easily select the language they need from a long list of languages (disclaimer: I am one of its developers)
• jquery.uls: an internal component of Universal Language Selector that has to be translated separately (for technical reasons)
• Cite: the extension that displays footnotes on Wikipedia
• Math: the extension that displays math formulas in articles
• Wikibase Client: the part of Wikidata that appears on Wikipedia, mostly for handling interlanguage links
• ProofreadPage: the extension that makes it easy to digitize PDF and DjVu files on Wikisource (this is relevant only if there is a Wikisource site in your language, or if you plan to start one)
• Wikibase Lib: additional messages for Wikidata
• WikiEditor: the toolbar for the wiki syntax editor
• Echo: the extension that shows notifications about messages and events (the red numbers at the top of Wikipedia)
• MobileFrontend: the extension that adapts MediaWiki to mobile phones
• ContentTranslation: the extension that helps to translate Wikipedia articles between languages (disclaimer: I am one of its developers)
• UploadWizard: the extension that helps people upload files to Wikimedia Commons comfortably
• Translate: the extension that powers translatewiki.net itself (disclaimer: I am one of its developers)
• Page Translation: the component of the Translate extension that helps to translate wiki pages (other than Wikipedia articles)
• Wikibase Repo: the extension that powers the Wikidata website
• VisualEditor: the extension that allows Wikipedia articles to be edited in a WYSIWYG style
• Wikipedia Android mobile app
• Wikipedia iOS mobile app
• Wikipedia KaiOS mobile app
• MediaWiki core: the base MediaWiki software itself!

I put MediaWiki core last intentionally. It’s a very large message group, with over 3000 messages. It’s hard to get it completed quickly, and actually, some of its features are not seen very frequently by users who aren’t site administrators or very advanced editors. By all means, do complete it, try to do it as early as possible, and get your friends to help you, but it’s also OK if it takes some time.

Getting all the things done

OK, so if you translate all the items above, you’ll make Wikipedia in your language mostly usable for most readers and editors. But let’s go further.

Let’s go further not just for the sake of seeing pure 100% in the statistics everywhere. There’s more.

As I wrote above, the software changes every single day. So do the translatable messages. You need to get your language to 100% not just once; you need to keep doing it continuously.

Once you make the effort of getting to 100%, it will be much easier to keep it there. This means translating some things that are used rarely (but used nevertheless; otherwise they’d be removed). This means investing a few more days or weeks into translating-translating-translating.

You’ll be able to congratulate yourself not only upon the big accomplishment of getting everything to 100%, but also upon the accomplishments along the way.

One strategy to accomplish this is translating extension by extension. This means, going to your translatewiki.net language statistics: here’s an example with Albanian, but choose your own language. Click “expand” on MediaWiki, then again “expand” on “MediaWiki Extensions” (this may take a few seconds—there are lots of them!), then on “Extensions used by Wikimedia” and finally, on “Extensions used by Wikimedia – Main”. Similarly to what I described above, find the smaller extensions first and translate them. Once you’re done with all the Main extensions, do all the extensions used by Wikimedia. This strategy can work well if you have several people translating to your language, because it’s easy to divide work by topic. (Going to all extensions, beyond Extensions used by Wikimedia, helps users of these extensions, but doesn’t help Wikipedia very much.)

Another fun strategy is quiet and friendly competition with other languages. Open the statistics for Extensions Used by Wikimedia – Main and sort the table by the “Completion” column. Find your language. Now translate as many messages as needed to pass the language above you in the list. Then translate as many messages as needed to pass the next language above you in the list. Repeat until you get to 100%.

For example, here’s an excerpt from the statistics for today:

Let’s say that you are translating to Georgian. You only need to translate 37 messages to pass Marathi and go up a notch (2555 – 2519 + 1 = 37). Then 56 messages more to pass Hindi and go up one more notch (2518 – 2463 + 1 = 56). And so on.

Once you’re done, you will have translated over 5600 messages, but it’s much easier to do it in small steps.

Once you get to 100% in the main extensions, do the same with all the Extensions Used by Wikimedia. It’s way over 10,000 messages, but the same strategies work.

Good stuff to do along the way

Invite your friends! You don’t have to do it alone. Friends will help you work more quickly and find translations to difficult words.

Never assume that the English message is perfect. Never. Do what you can to improve the English messages. Developers are people just like you are. There are developers who know their code very well, but who are not the best writers. And though some messages are written by professional user experience designers, many are written by the developers themselves. Developers are developers; they are not necessarily very good writers or designers, and the messages that they write in English may not be perfect. Also, keep in mind that many, many MediaWiki developers are not native English speakers; a lot of them are from Russia, Netherlands, India, Spain, Germany, Norway, China, France and many other countries. English is foreign to them, and they may make mistakes.

So if anything is hard to translate, of if there are any other problems with the English messages to the translatewiki Support page. While you are there, use the opportunity to help other translators who are asking questions there, if you can.

Another good thing is to do your best to try using the software that you are translating. If there are thousands of messages that are not translated to your language, then chances are that it’s already deployed in Wikipedia and you can try it. Actually trying to use it will help you translate it better.

Whenever relevant, fix the documentation displayed near the translation area. Strange as it may sound, it is possible that you understand the message better than the developer who wrote it!

Before translating a component, review the messages that were already translated. To do this, click the “All” tab at the top of the translation area. It’s useful for learning the current terminology, and you can also improve them and make them more consistent.

After you gain some experience, create or improve a localization guide in your language. There are very few of them at the moment, and there should be more. Here’s the localization guide for French, for example. Create your own with the title “Localisation guidelines/xyz” where “xyz” is your language code.

As in Wikipedia itself, Be Bold.

OK, so I got to 100%, what now?

Well done and congratulations.

Now check the statistics for your language every day. I can’t emphasize enough how important it is to do this every day. If not every day, then as frequently as you can.

The way I do this is having a list of links on my translatewiki.net user page. I click them every day, and if there’s anything new to translate, I immediately translate it. Usually there are just a few new messages to translate; I didn’t measure precisely, but usually it’s fewer than 20. Quite often you won’t have to translate from scratch, but to update the translation of a message that changed in English, which is usually even faster.

But what if you suddenly see 200 new messages to translate or more? It happens occasionally. Maybe several times a year, when a major new feature is added or an existing feature is changed. Basically, handle it the same way you got to 100% before: step by step, part by part, day by day, week by week, notch by notch, and get back to 100%.

But you can also try to anticipate it. Follow the discussions about new features, check out new extensions that appear before they are added to the Extensions Used by Wikimedia group, consider translating them when you have a few spare minutes. At the worst case, they will never be used by Wikimedia, but they may be used by somebody else who speaks your language, and your translations will definitely feed the translation memory database that helps you and other people translate more efficiently and easily.

Consider also translating other useful projects: OpenStreetMap, Etherpad, Blockly, Encyclopedia of Life, etc. Up to you. The same techniques apply everywhere.

What do I get for doing all this work?

The knowledge that thanks to you, people who read in your language can use Wikipedia without having to learn English. Awesome, isn’t it? Some people call it “Good karma”. Also, the knowledge that you are responsible for creating and spreading the terminology in your language for one of the most important and popular websites in the world.

Oh, and you also get enormous experience with software localization, which is a rather useful and demanded job skill these days.

Is there any other way in which I can help?

Yes!

If you find this post useful, please translate it to other languages and publish it in your blog. No copyright restrictions, public domain (but it would be nice if you credit me and send me a link to your translation). Make any adaptations you need for your language. It took me years of experience to learn all of this, and it took me about four hours to write it. Translating it will take you much less than four hours, and it will help people be more efficient translators.

Thanks!

The nomination of Amy Coney Barrett to the US Supreme Court has brought the issue of abortion access back into the forefront and people try to understand the impact her confirmation might have on abortion rights in the US.

I grew up in a country where abortion was neither legal nor uncommon. While I never found myself in need of access to an abortion, I had friends and acquaintances who did. Whether a person was able to find a doctor willing to perform the procedure, or whether they tried to source an abortifacient from a pharmacist or someone who knew about herb, they did so with only the minimum of knowledge. In those pre-internet days, information was hard to come by, and accurate information harder still. These days things are different, there’s a wealth of information available online, but people have a hard time deciding what to trust.

This summer, I worked with a Wiki Scholars course sponsored by the Society of Family Planning (SFP). Like the three previous iterations of the course, the participants worked on a range of articles related to reproductive health, including topics like Abortion in North Carolina, Abortion in Wisconsin, ectopic pregnancy and healthcare and the LGBT community.

Ideally, there should never be need for self-induced abortion, but as long as demand for abortion doesn’t match the availability of abortion performed under the supervision of a medical provider, it’s important for Wikipedia to have the best information possible. While people should never be coming to Wikipedia for medical advice, the fact that they do means that we need to have the best information possible in Wikipedia’s medical articles. A participant in this SFP class improved the self-induced abortion article, as have participants in previous groups.

Aid Access is an organization which provides access to medical abortion by mail in the United States. Their Wikipedia article was created by a participant in this class. Other people worked on the medical abortion (also known as medicinal abortion) article, an article that has also seen improvements from previous groups. Approximately 40% of all abortions in the United States use medication to cause abortion, and experts have expected that number to increase since the beginning of the COVID-19 pandemic. Now, readers looking for more information about telehealth options for abortion care have better information thanks to these new Wikipedia editors.

Regardless of how things proceed in the coming years in the US, people will continue to see pregnancy terminations in places where the option of doing it safely is either not available or not affordable. And even where access to safe, affordable abortion services do exist, access to accurate information allows them to make better decisions for themselves. I am proud to have had the opportunity to support these remarkable Wiki Scholars, many of whom were working in hospitals while the COVID-19 pandemic rages.

To see a current list of course offerings, visit learn.wikiedu.org. To sponsor a similar initiative to increase access to crucial information, visit partner.wikiedu.org.

Geneva, Switzerland, 22 October 2020 — The World Health Organization (WHO) and the Wikimedia Foundation, the nonprofit that administers Wikipedia, announced today a collaboration to expand the public’s access to the latest and most reliable information about COVID-19.

The collaboration will make trusted, public health information available under the Creative Commons Attribution-ShareAlike license at a time when countries face continuing resurgences of COVID-19 and social stability increasingly depends on the public’s shared understanding of the facts.

Through the collaboration, people everywhere will be able to access and share WHO infographics, videos, and other public health assets on Wikimedia Commons, a digital library of free images and other multimedia.

With these new freely-licensed resources, Wikipedia’s more than 250,000 volunteer editors can also build on and expand the site’s COVID-19 coverage, which currently offers more than 5,200 coronavirus-related articles in 175 languages. This WHO content will also be translated across national and regional languages through Wikipedia’s vast network of global volunteers.

“Equitable access to trusted health information is critical to keeping people safe and informed during the COVID-19 pandemic,” said Dr. Tedros Adhanom Ghebreyesus, Director-General of the World Health Organization. “Our new collaboration with the Wikimedia Foundation will increase access to reliable health information from WHO across multiple countries, languages, and devices.”

Since the beginning of the pandemic, WHO has taken steps to prevent an “infodemic”— defined by the organization as “an overabundance of information and the rapid spread of misleading or fabricated news, images, and videos.”

Wikipedia editors have similarly been on the frontlines of preventing the spread of misinformation surrounding the coronavirus, ensuring information about the pandemic is based on reliable sources and updated regularly on Wikipedia.

By making verified information about the pandemic available to more people on one of the world’s most-visited knowledge resources, the organizations aim to help curb this infodemic and ensure everyone can access critical public health information.

“Access to information is essential to healthy communities and should be treated as such,” said Katherine Maher, CEO at the Wikimedia Foundation. “This becomes even more clear in times of global health crises when information can have life-changing consequences. All institutions, from governments to international health agencies, scientific bodies to Wikipedia, must do our part to ensure everyone has equitable and trusted access to knowledge about public health, regardless of where you live or the language you speak.”

WHO has served as the leading international health agency spearheading the global response to the coronavirus outbreak. Since the beginning, WHO has worked to rapidly establish international coordination, scale up country readiness and response, and accelerate research and innovation. Today, as information on the transmission and epidemiology of the virus evolves, WHO continues to provide essential guidance and public health recommendations to governments, communities and individuals everywhere.

At the same time, Wikipedia volunteer editors, many of whom are from the medical community, have been creating, updating, and translating Wikipedia articles with information from reliable sources about the pandemic. As one of the top ten sites in the world, studies have shown that Wikipedia is one of the most frequently viewed sources for health information.

At the moment, readers can access WHO’s mythbusting series of infographics on Wikimedia Commons. The infographics, which focus on addressing common misconceptions about COVID-19, are also available for Wikipedia editors to incorporate into Wikipedia articles.

In the coming months, the Wikimedia Foundation and WHO will continue uploading resources to Wikimedia Commons and collaborating with Wikipedia volunteer editors to better understand gaps in information needs on Wikipedia articles related to COVID-19 and how WHO resources can help fill these gaps.

Additionally, under the Creative Commons Attribution-ShareAlike license, other organizations, individuals, and websites can more easily share these materials on their own platforms without having to address stricter copyright restrictions.

About the World Health Organization

The World Health Organization provides global leadership in public health within the United Nations system. Founded in 1948, WHO works with 194 Member States, across six regions and from more than 149 offices, to promote health, keep the world safe and serve the vulnerable. Our goal for 2019-2023 is to ensure that a billion more people have universal health coverage, to protect a billion more people from health emergencies, and provide a further billion people with better health and wellbeing.

For updates on COVID-19 and public health advice to protect yourself from coronavirus, visit www.who.int and follow WHO on Twitter, Facebook, Instagram, LinkedIn, TikTok, Pinterest, Snapchat, YouTube, and Twitch.

About the Wikimedia Foundation 

The Wikimedia Foundation is the nonprofit organization that operates Wikipedia and the other Wikimedia free knowledge projects. Our vision is a world in which every single human can freely share in the sum of all knowledge. We believe that everyone has the potential to contribute something to our shared knowledge, and that everyone should be able to access that knowledge freely. We host Wikipedia and the Wikimedia projects, build software experiences for reading, contributing, and sharing Wikimedia content, support the volunteer communities and partners who make Wikimedia possible, and advocate for policies that enable Wikimedia and free knowledge to thrive. The Wikimedia Foundation is a United States 501(c)(3) tax-exempt organization with offices in San Francisco, California, USA.

Press contacts 

WHO
mediainquiries@who.int

Wikimedia Foundation
press@wikimedia.org

This fall, we’re celebrating the 10th anniversary of the Wikipedia Student Program with a series of blog posts telling the story of the program in the United States and Canada.

Ten years ago when I joined the team that started what became the Wikipedia Student Program, we didn’t have any specialized software to organize classroom assignments and keep track of what student editors were doing. We had to work with what the good Ward gave us: the near-infinite palimpsest of wiki pages.

Several years before joining Wikimedia Foundation, I had attended a talk by longtime Wikimedian Erik Möller that really stuck with me. Erik laid out his vision of the wiki as a technology that empowers users to become technologists themselves — to use the flexibility of wikitext and templates to build the tools they need. I found this idea beautiful and powerful. As an historian with no background in programming, I had never thought of myself as a technologist before. But that sense of being able to make whatever you needed for the encyclopedia — that this technology wasn’t magic, but text — is I think what pulled me into Wikipedia in the first place.

For the first several terms of the education program, wiki tools did much of what we needed. We built templates to provide some structure to wiki course pages, and to give instructors a clear workflow for signing up and getting started. We manually collected usernames, to make sure we knew who the student editors were for each course. For my part, I dove deeper than I ever had into templates, building a set of training modules for introducing instructors and students to the Wikipedia basics. But as the number of courses grew, we strained the limits of what was practical with just wikitext and templates. We needed more powerful and specialized software.

Course: Oblivion

In 2012, Wikipedia assignments went — perhaps a little too boldly — where none had gone before: to a new MediaWiki extension built just for the purpose of supporting course projects. The initial debut of this software created a new namespace on Wikipedia, “Course:”. Unfortunately, deploying this new namespace inadvertently wiped out an article about an episode of Star Trek: Voyager, the auspiciously titled “Course: Oblivion“. It had to be turned off immediately, and the joke after that among Wikimedia staff was “whatever you do, don’t piss off the Star Trek editors”. (Looking over the discussions today, everyone seems to have been quite nice about it.)

The aftermath of that deployment is when I first started getting involved with software development. I was tasked to work with the editing community and the developers to find a way forward so that the extension could be re-enabled. My impression at the time was that everything seems so complicated, it’s a wonder that any software ever gets better or that anyone ever understands how it works. But a few months after the initial deployment, I organized a Request for Comment to redeploy the extension in time for the Fall term.

With the extension up and running again, I started compiling an ever-growing list of ways to make this new course management system better — to make work more smoothly with the rest of Wikipedia, to fix the parts that new instructors and students would get stuck on. I also started looking into the code myself. With an enormous amount of help from a new Wikimedia engineer, Andrew Russell Green, I managed to add a new feature to the education program extension, an API for listing all the students in a course and all the articles they were assigned.

The combination of a functional (if buggy) course page system and a whole lot of wiki templates gave the education program a chance to develop over the next few years, becoming an accepted (if occasionally controversial) part of English Wikipedia. It took root in a growing number of other languages as well, as the education team at Wikimedia worked to foster similar programs around the globe. Unfortunately, the extension was increasingly viewed as a technological dead end by the Wikimedia tech team — in fact, one they were eager to turn off because of how much work it took to keep it up and running through each new version of the core wiki software.

The Dashboard

2014 marked a major change for education programs in the Wikimedia community, and a new direction for the technology that supports it. That year, part of the education team at Wikimedia Foundation spun off into a new independent nonprofit focused on English Wikipedia and North America: Wiki Education. I joined as Product Manager, and my first task was to hire a software agency to build a whole new suite of tools to power Wikipedia assignments going forward.

We started out with a web app, the Assignment Design Wizard, that gave instructors a series of choices about how to implement a Wikipedia assignment. At the end, it would translate those choices into a set of templates for a course page and then post them to Wikipedia, integrating with the education program extension. The next term (Spring 2015) we took it much further, launching the first version of the Wiki Education Dashboard. Built with Ruby on Rails and the JavaScript framework React, the Dashboard has been the main focus of our technology efforts ever since.

My role gradually shifted, as I took an increasingly active hand in developing the Dashboard. At first, I learned how to save changes so that I could update instructions and adjust the content of automated wiki edits. From there, I began diving into the Ruby programming language, and was soon adjusting the system’s logic and fixing bugs. By 2016, we were scaling back our budget for software development, but I was also starting to become comfortable enough with the Dashboard code to push things forward myself, developing small new features and doing a large amounts of “refactoring” — rewriting code to make it simpler, more understandable, and easier to extend.

New wikis, new challenges

The Dashboard gave us a platform we could continually extend and adjust to meet the needs of a growing Wikipedia Student Program. With a heroic effort from Wikimedia engineer (and Ruby enthusiast) Adam Wight, we also began taking what we’d built and making into a possible replacement for the MediaWiki education program extension more generally. Wiki Education stopped using the extension when we launched the Dashboard, but it was still being used widely by other Wikipedia education programs globally. To make the Dashboard work for the rest of the Wikimedia movement, we needed it to be compatible with every language version of Wikipedia (and any Wikimedia project). This meant internationalizing the interface, but also integrating the concept of multiple independent wikis throughout the system. The result, after months of work, was the launch of Programs & Events Dashboard in June 2016.

In the years since, the shared Dashboard codebase (which powers both Wiki Education Dashboard and Programs & Events Dashboard) has become a critical piece of infrastructure for not just the Wikipedia Education Program, but a whole host of efforts to bring new contributors to Wikimedia projects. As of October 2020, Programs & Events Dashboard has been used by more than 53,000 people across more than 250 wikis. It has provided a new home for Wikipedia classroom assignments around the world — allowing the MediaWiki education program extension to be retired in 2018.

One of the biggest challenges since 2016 has been keeping up with the scale at which the Dashboard is being used. I’ve had to learn a lot about software architecture and system administration, optimizing the code and finding creative ways to handle the load of tens of thousands of editors, millions of articles, and tens of millions of edits. Another big challenge has been adapting the Dashboard’s user experience to the wide variety of ways people are using, or want to use, it. Initially, it was designed around Wiki Education’s Student Program — college students working on English Wikipedia, with support from Wiki Education staff. Since then, it’s been used for: edit-a-thon series, Wikipedia writing contests, Wikimedian-in-Residence and Visiting Scholar projects, Wikidata curation drives; Wiki Education’s Scholars & Scientists program, and much more. We’ve made it more flexible, added new features to support specific types of programs, and found ways for program organizers and Wiki Education staff to do more with less time.

A big part of the Dashboard story is the interns and volunteers who’ve built new features, fixed bugs, and generally made it better over the years. More than 130 people have contributed since 2015, across nearly 14,000 changes (“commits”). I’m grateful for everyone whose been part of this technology journey with me (both through the Dashboard project, and elsewise), and I can’t wait to see what — and whom — the future brings.

Image credit: Ralf Roletschek, GFDL 1.2, via Wikimedia Commons

Heidi Raatz is Owner and Consultant at Collections Management Solutions, LLC. She recently took the Wikidata Training course through Wiki Education and reflects on her experience with the Wikimedia community in this guest blog post.

In September I had the opportunity to take the three-week Wikidata training course offered through Wiki Education. What an amazing experience. I especially want to thank Will Kent and Ian Ramjohn for leading the course instruction. Will in particular was incredibly helpful with participant questions, weaving these into the course sessions and offering additional guidance, suggesting approaches, and recommending helpful tools.

The course offered a solid foundation for understanding Wikidata and the capacity for collaborative approaches to linked open data and information sharing. Experiencing Wikidata as someone with an extensive professional background in the cultural heritage sector, it was great to see so many GLAM Wiki projects already in place, bringing various communities and institutions into a position to both contribute to and benefit from this powerful shared knowledge base. I was inspired to see how many GLAMs have come to recognize and appreciate Wikidata as a truly valuable repository of linked data. It was abundantly clear through the coursework that Wikidata can have an impact on collection visibility and enrichment via connecting institutional data with other related linked data sets, and that Wikidata is further strengthened through GLAM contributions by supporting, expanding and amending Wikidata items with additional authoritative data. The potential and promise of Wikidata is that there is a ready case for using Wikidata to enrich collections data for GLAMs.

Another vital issue addressed during the course is the mining of Wikidata as a readily available linked data set for training AI, and the use of Wikidata information as a knowledge base. Critically, the structure of Wikidata has this great capacity to make it easier to identify and address gaps in the knowledge record, especially in areas of language. There is so much potential to reach new communities of participants and expand the information available in Wikidata, and because Wikidata is the centralized data repository for all Wikimedia projects, to use Wikidata to expand and address issues of representation in Wikipedia and other Wikimedia projects. It is vitally important to identify and address these gaps in our shared knowledge resources; to be cognizant of what is not included and expand knowledge bases such as Wikidata so that they preset a more whole picture. As an information professional I view this as an opportunity to engage new communities and expand our knowledge resources for peoples, expressions, beliefs and ways of being which are currently under represented in Wikidata and Wikipedia, and one way to begin to address the systemic bias existing in our knowledge resources. This is also an area I view as promising for my current professional practice as a freelancer in the cultural heritage sector. It gives me the opportunity to introduce Wikidata and the concepts of linked open data to communities lacking the funding or resources more readily available to established cultural heritage institutions.

The course met my expectations and then some; there was so much information to try to absorb. There are so many different tools and angles of approach to editing in Wikidata. From working on individual items, to doing batch editing work; from using tools to expand existing items or find gaps and fill in existing data. It is a little daunting to think of where to begin, especially if one is not affiliated with a particular institutional collection or working on a well-defined cataloging project. It can be challenging to identify one’s focus, identify a project, and fix on where you can best contribute. But the course has been an experience of great knowledge sharing; it has been a brain expansion and definitely gives me a lot to build on.

The course covered a lot of material in a condensed amount of time, so I will no doubt be returning to the course dashboard and my notes to refresh, review, and reflect on what I learned. The course afforded me hands-on opportunities to gain invaluable confidence in editing Wikidata items and using various tools. The course also deepened my understanding of the processes for expanding, amending, and creating new Wikidata items, taught me how to create and leverage queries, and overall expanded my knowledge of Wikidata tools, projects and opportunities. I have gained capacity to share what I have learned to better assist individuals, communities, and institutions in contributing to and benefitting from this powerful shared knowledge base. As an individual Wikidata editor, I plan to use this new expertise to continue to work on improving Wikidata items and properties and engaging with the Wikidata community on future projects. I cannot recommend the Wikidata training course through Wiki Education highly enough. Thank you again for the opportunity.

Interested in taking a course like the one Heidi took? Visit wikiedu.org/wikidata to see current course offerings.

This fall, we’re celebrating the 10th anniversary of the Wikipedia Student Program with a series of blog posts telling the story of the program in the United States and Canada.

Saying that Wikipedia has changed a lot over the past ten years is an understatement. One of the ways that Wikipedia has changed the most is a need for expert knowledge and engagement with expert communities. One of Wikipedia’s enduring strengths is that it is the encyclopedia that anyone can edit. This democratizing feature is what has made the Wikipedia community what it is. It doesn’t mean, however, that Wikipedia is averse to having experts contribute to it. There are essential roles for amateurs and experts alike to have on Wikipedia. Wiki Education’s programs have engaged experts over the last 10 years and, we’ll share what we have learned from this engagement.

The Student Program

Pursuing experts does not mean excluding non-experts, amateurs, or newcomers. The emphasis on non-experts contributing to Wikipedia is one of its enduring strengths. At the same time it is also a reason why institutions of expertise have tension with Wikipedia. Academia used to frown upon Wikipedia. The rift still exists, but experts are beginning to embrace Wikipedia. The Wikipedia Student Program helps to bridge that. Experts should feel compelled contribute to Wikipedia because it is where people go for information. Cultivating responsibility for experts to share their knowledge is not currently built into academic systems. It is our hope that programs like this can advocate for that responsibility, space, and time for experts to contribute.

The Student Program promotes students as experts. Although students make the contributions, they are doing this under the guidance of their professors. As the facilitators of these courses, professors are able to identify references, share articles for improvement, and help with phrasing in the articles. Students are able to become experts as they evaluate sources, draft articles, and synthesize them for Wikipedia. Writing for a wide audience also instils a sense of responsibility that a research papers, only read by a professor and maybe a TA, would not. As a result, this gives students editing Wikipedia a chance to feel like an expert and be an expert.

The title of expert can be shared by both the instructor and student. Redefining what being an expert means places a particular emphasis on the privilege of access — access to information behind paywalls, access to time, and access to resources to edit, which encourages the sharing of expertise with the world and not just keeping it in colleges and universities. Take a look at these articles, ranging from a common topic like, sand to a newsworthy topic like Refugees of the Syrian Civil wars in Lebanon to see their impact.

This makes Wikipedia into a space where experts feel compelled to contribute. Everyone benefits from higher quality content on Wikipedia. Having concepts that are part of experts’ research be well represented will only help educate and courage more research in those areas.

The Scholars and Scientists Program

The Scholars and Scientists Program began as a way to more directly engage with experts and expert knowledge. The notion that Wikipedia is hostile to experts is now a dated view. Everyone goes to Wikipedia to learn about things — for voting, for self diagnosing, for school, for curiosities. Wikipedia’s popularity backs up the consensus that this is true. In spite of this, contributing is not without its challenges. Lack of time, transitioning from academic prose to Wikipedia-style writing, conflict of interest (wanting to write about their areas of expertise), verifiability not truth, and no original research work against the structure that a lot of academics are used to. Having no direct benefit for their career — not part of tenure or easily to include on a CV, lack of time — defines contributing to Wikipedia as a volunteer experience. So Wiki Education created a formal space in which experts can work, be recognized for their work, and improve Wikipedia in the process. The program began in 2018 with 100 people applying for 9 slots: It was clear that there was interest.

An example like inhomogeneous cosmology demonstrates how expert knowledge can contribute to a complex topic that only a small community of people may know about. Having articles like this allow others to learn about a topic that would otherwise be less accessible. Similarly, the article for the 19th Amendment to the US Constitution demonstrates how expert knowledge can elevate an accessible topic from an average article to a Good Article. Ultimately this program serves as a funnel for WikiProjects, creating alumni groups, and drawing more attention to professional organizations themselves.

A different side of the same Scholars and Scientists’ coin is the newer Wikidata program. Starting in 2019, this program works to build off the engagement model that both of these other programs use. As Wikipedia has changed over the last ten years, the Wikimedia movement has also grown. In an effort to unite Wikipedia’s 300+ languages though structured data, Wikidata serves a unique purpose in the Wikimedia landscape. Working with structured or linked data requires a different set of skills than editing Wikipedia does. The two are, however, united through the community experience and that they are projects that anyone can edit.

The goal of the Wikidata courses is to engage data stewards and experts across several fields — museums, libraries, cultural heritage institutions, government organizations, non-profits — to teach them how to contribute meaningfully to Wikidata. Again newcomers and experts alike both play essential roles in Wikidata. Reaching out and encouraging more expert use builds the community not only in a people-oriented sense, but also access to more data. As of September 2020, this program has engaged with just under 200 experts who have edited more than 17,000 items on Wikidata. You can see more statistics here.

In being both human and machine readable, part of Wikidata’s influence is obscured by the role is plays with digital assistants, AI, and its increasing structural on in the internet. Having expertise present on Wikidata will not only improve data quality for other Wikimedia projects to take advantage of, but it will also help enrich the internet’s linked data content by having more institutions regularly contribute their data.

As we look forward to ten more years of all of these programs engaging with all kinds of audiences, we continue to actively explore new ways to engage with subject matter experts. These ways include, always testing out new curricula, delivery options, presenting at conferences on our results, and expanding programming into other Wikimedia projects. As we explore these new avenues for deeper and higher quality engagement, we hope that you will continue to participate in our programs and tell others about them. It is because of our active community that all of this is successful. We couldn’t do it without you and we’re eager to keep going.

This blog post drew heavily from the presentation Engaging Experts Three Ways: How Wiki Education is building a bridge between Wikipedia and Subject-Matter Experts by Blumenthal, Kent, and McGrady. Click Day 1, Session 3 32-155, Wiki Conference North America 2019 in the link to view.

By Dr. Keren Shatzman, Wikimedia Israel and Elisabeth Giesemann, Wikimedia Deutschland

Wikidata is a free and open knowledge base that allows humans and machines to access linked data. To support the international Wikidata community, Wikimedia Israel has developed a tutorial for the Query Service. With the tutorial, the chapter aims to empower new users to query Wikidata, which currently holds almost 90 million items. 

Tell us a little about your background and who you are!

My background is in academia. I did my Ph.D. and studied experimental psychology. While I worked in academia, many institutions were realizing that the business model of commercial publishers was unfair. Publishers get all the data, articles, and the work of the editors for free, and then they charge exorbitant fees from the libraries. This also became a motivation for me, shaking up this “world of paywall.” Most research is already publicly funded, so the public should be able to access and enjoy the fruits of that research. At Wikimedia Israel, I started working as a coordinator for academic projects. Now, I am also the Wikidata Project Coordinator.

What is the Wikimedia community in Israel like? 

The community in Israel is mostly Wikipedia editors. There are very few people who have Wikidata as their focus. As a chapter, this is something we are trying to change. Israel is a small country, but we have a disproportionately large high-tech industry. We are always looking for different ways to get these developers, engineers, and programmers on board. However, they are generally very busy people, who work long hours and often don’t have a lot of extra time to volunteer. So, we try to find scenarios where people gain something from contributing. Very few people volunteer just because they believe in free knowledge; most people want to gain a more immediate reward. 

Why did you decide to develop a tutorial?

I give a lot of talks and workshops to introduce Wikidata. Once participants understand the concept of linked data and see what the query service is capable of, they are very excited. Their eyes light up because the database is so varied; it includes “everything from everything” in all countries and languages and allows you to analyze data in a way that no other information service can do for you. You can research topics that you wouldn’t find in any other database. 

Yet, it is not possible to just use natural language to query; you have to learn SPARQL. So, we figured that teaching SPARQL is the best way to get people to fully grasp Wikidata. Since it is only a query language, it is teachable and limited in scope. People can learn it after a few lessons and get involved. Once they get involved, maybe they will also contribute to the data. If you make a query on French films in the sixties and you see that a third of the films don’t have a producer, you can say “Let’s complete this dataset, let me add what’s missing.” 

Who else do you target with the tutorial? 

We have many different target groups: librarians and information scientists, students, and the technology crowd. Information Scientists and librarians are closer to the content, and easily get how Wikidata is useful for organizing knowledge, but most have no experience with SPARQL.

Another target group is people who are interested in a particular topic, for example, film buffs or fans of a particular sport or team. In the past, we could try to encourage them to write Wikipedia articles about their topic of interest, but now they can also gather data about that topic. For example, a person may collect data about “French film in the sixties” and get it organized in a way that allows an overview or to present a new idea about it.

Why did you choose Star Wars as an example for the tutorial?

This was one of the hardest choices! I wanted something that would be universal. Everybody knows Star Wars.t is not just a regional thing; it’s not that in one part of the world, people think Star Wars is good, and in the other, they think Star Wars is bad. Also, I noticed that many of the instructional materials that Wikimedia produces have their background in GLAM, and often these examples can be quite elitist. They talk about Rembrandt paintings or Mozart pieces, but somebody in Southeast Asia doesn’t necessarily connect to these examples. I thought that if I am doing a tutorial for everyone, I want to use something that many people recognize. 

Wikimedia Israel’s general attitude is that since we have such a small potential audience – just nine million Hebrew speakers – we need to encourage people to make a one-time contribution to Wikimedia projects (Wikipedia, Commons, Wikidata, etc…) on a topic that interests them. We don’t try to turn them into Wikipedians or Wikimedians. Whether they do it on a topic in a school or university project or within other activities, once a person realizes that they are able to contribute, maybe they will do it once more. If it really interests them, they might continue to do that. 

Our aim is to show people that it is not so difficult to make a contribution. Coming from this attitude, we try to make everything very accessible. Star Wars might not be CC-BY-SA, but that was less of a consideration for us than creating an easy entry point for people who don’t know anything about Wikidata. 

What’s the most interesting thing you found out by querying yourself?

One of the things that really surprised me is how, in some Wiki projects, a lot of the information is updated so quickly, while for other projects, it is rather slow. For example, I looked at the Academy Awards, and the information on Wikipedia about them is fantastic. Then I looked at Wikidata and noticed that it was not as complete, which was shocking, because I thought it is so easy to transfer the info into this kind of data. 

It became even clearer to me how much we need to get more people to look at Wikidata – not necessarily because they are data scientists, but because they love football, or they love cinema.ll of these topics attract people. “We need to show that people can do work that means something to them personally.” We just need to show them that they can do meaningful work or work that relates to personal matters. For example, my sister lives in Tenerife. When I visited her and traveled on the island I was told that some Star Wars film was shot on location there. So I ran a Wikidata query for films shot on location in the Canary Islands. Turns out “Solo: A Star Wars Story” was partly shot on Fuerteventura, not on Tenerife.  

How does Wikidata support the multilingual nature of your work?

The core work of Wikimedia Israel is traditionally aimed at Hebrew and Arabic Wikipedia, but Wikidata introduces a whole new concept. It is important to understand that Hebrew Wikipedia is a completely different site than Arabic Wikipedia. In fact, you will find many articles that tell a completely different story. Wikidata is the same data, but you present it in different languages. The information isn’t given in a way that it is already interpreted. No matter what language you speak or what community you belong to, it is the same data. 

When we started developing the tutorial, we first said that we want to do it in Hebrew, but I felt like that it is a lot of investment for a small potential of people, even if we do it also in Arabic. So we did it in English and will translate it afterward. With the technical format that we have in WordPress, it is also easy to translate. It was the first time we developed a tutorial not just for Israel, but for the whole international movement. 

If other chapters are interested in translating it into their language it is very easy to do, you only need to translate the text; the exercises are the same. We are really interested in this kind of international collaboration and seeing if we can get the website in Spanish, French, and German. Also, we want to ask the people in all communities who do Wikidata outreach whether they are missing in the tutorial or want to change something. It is exciting for us to rise above our small chapter and see what we can offer. We want to give something back.

Share your feedback

To share your thoughts about the tutorial with Wikimedia Israel, please write to wdqs@wikimedia.org.il

About this post

Featured image credit: The Wikidata Query Service Tutorial, Dr. Keren Shatzman and Elisabeth Giesemann, CC BY-SA 4.0

—I suppose you are an entomologist?—I said with a note of interrogation.

—Not quite so ambitious as that, sir. I should like to put my eyes on the individual entitled to that name! A society may call itself an Entomological Society, but the man who arrogates such a broad title as that to himself, in the present state of science, is a pretender, sir, a dilettante, an impostor! No man can be truly called an entomologist, sir; the subject is too vast for any single human intelligence to grasp.

The Poet at the Breakfast Table (1872) by Oliver Wendell Holmes, Sr. 

A collection of biographies with surprising gaps (ex. A.D. Imms)

The history of Indian interest in insects has been approached by many writers and there are several bits and pieces available in journals and various insights distributed across books. There are numerous ways of looking at how people viewed insects over time. One of these is a collection of biographies, some of which includes uncited verbatim (and not even within quotation marks) accounts  from obituaries. This collation by B.R. Subba Rao who also provides a few historical supporting material to thread together the biographies. Keeping Indian expectations in view, bot Subba Rao and the agricultural entomologist M.A. Husain play to the crowd in their versions. Husain wrote in pre-Independence times where there was a need for Indians to assert themselves in their conflict with colonial masters. They begin with mentions of insects in ancient Indian texts and as can be expected there are mentions of honey, shellac, bees, ants, and a few nuisance insects. Husain takes the fact that the term Satpada षट्पद or six-legs existed in the 1st century Amarakosa to make the claim that Indians were far ahead of time because Latreille's Hexapoda, the supposed analogy, was proposed only in 1825. Such one-up-manship misses the fact that science is not just about terms but  also about structures and one can only assume that they failed to find the development of such structured ideas in the ancient texts that they examined. The identification of species in old texts also leave one wondering about the accuracy of translations. For instance K.N. Dave translates a verse from the Atharva-veda and suggests an early date for knowledge of shellac. This interpretation looks dubious and sure enough, Dave has been critiqued by an entomologist, Mahdihassan. One organism named in the texts as the indragopa (Indra's cowherd) is supposedly something that appears after the rains. Some Sanskrit scholars have, remarkably enough, identified it with a confidence that no coccidologist ever had as the cochineal insect (the species Dactylopius coccus is South American!), while others identify it as a lac insect, a firefly(!) or as Trombidium (red velvet mites) - the last for matching the blood red colour mentioned in a text attributed to Susrutha. To be fair, ambiguities in translation are not limited to those dealing with Indian writing. Dikairon (Δικαιρον), supposedly a highly-valued and potent poison from India was mentioned in the work Indika by Ctesias 398 - 397 BC. One writer said it was the droppings of a bird. Valentine Ball thought it was derived from a scarab beetle. Jeffrey Lockwood claimed that it came from the rove beetles Paederus sp. And finally a Spanish scholar states that all this was a misunderstanding and that Dikairon was not a poison, and - believe it or not - was a masticated mix of betel leaves, arecanut, and lime! 

 

One gets a far more reliable idea of ancient knowledge and traditions from practitioners, forest dwellers, the traditional honey-harvesting tribes, and similar people that have been gathering materials such as shellac and beeswax. Unfortunately, many of these traditions and their practitioners are threatened by modern laws, economics, and cultural prejudice. These practitioners are being driven out of the forests where they live, and their knowledge was hardly ever captured in writing. The writers of the ancient Sanskrit texts were probably associated with temple-towns and other semi-urban clusters and it seems like the knowledge of forest dwellers was never considered merit-worthy.

A more meaningful overview of entomology may be gained by reading and synthesizing a large number of historical bits, and of which there are a growing number. The 1973 book published by the Annual Reviews Inc. should be of some interest. I have appended a selection of sources that I have found useful in adding bits and pieces to form a historic view of entomology in India. It helps however to have a broader skeleton on which to attach these bits and minutiae. Here, there area also truly verbose and terminology-filled systems developed by historians of science (for example, see ANT). I prefer an approach that is free of a jargon overload and like to look at entomology and its growth along three lines of action - cataloguing with the main product being collection of artefacts and the assignment of names, communication and vocabulary-building are social actions involving groups of interested people who work together with the products being scholarly societies and journals, and pattern-finding where hypotheses are made, and predictions tested. I like to think that anyone learning entomology also goes through these activities, often in this sequence. With professionalization there appears to be a need for people to step faster and faster into the pattern-finding way which also means that less time is spent on the other two streams of activity. The fast stepping often is achieved by having comprehensive texts, keys, identification guides and manuals. The skills involved in the production of those works - ways to prepare specimens, observe, illustrate, or describe are often not captured by the books themselves.

Cataloguing

The cataloguing phase of knowledge gathering, especially of the (larger and more conspicuous) insect species of India grew rapidly thanks to the craze for natural history cabinets of the wealthy (made socially meritorious by the idea that appreciating the works of the Creator was as good as attending church)  in Britain and Europe and their ability to tap into networks of collectors working within the colonial enterprise. The cataloguing phase can be divided into the non-scientific cabinet-of-curiosity style especially followed before Darwin and the more scientific forms. The idea that insects could be preserved by drying and kept for reference by pinning, [See Barnard 2018] the system of binomial names, the idea of designating type specimens that could be inspected by anyone describing new species, the system of priority in assigning names were some of the innovations and cultural rules created to aid cataloguing. These rules were enforced by scholarly societies, their members (which would later lead to such things as codes of nomenclature suggested by rule makers like Strickland, now dealt with by committees that oversee the  ICZN Code) and their journals. It would be wrong to assume that the cataloguing phase is purely historic and no longer needed. It is a phase that is constantly involved in the creation of new knowledge. Labels, catalogues, and referencing whether in science or librarianship are essential for all subsequent work to be discovered and are essential to science based on building on the work of others, climbing the shoulders of giants to see further. Cataloguing was probably what the physicists derided as "stamp-collecting".

Communication and vocabulary building

The other phase involves social activities, the creation of specialist language, groups, and "culture". The methods and tools adopted by specialists also helps in producing associations and the identification of boundaries that could spawn new associations. The formation of groups of people based on interests is something that ethnographers and sociologists have examined in the context of science. Textbooks, taxonomic monographs, and major syntheses also help in building community - they make it possible for new entrants to rapidly move on to joining the earlier formed groups of experts. Whereas some of the early learned societies were spawned by people with wealth and leisure, some of the later societies have had other economic forces in their support.

Like species, interest groups too specialize and split to cover more specific niches, such as those that deal with applied areas such as agriculture, medicine, veterinary science and forensics. There can also be interest in behaviour, and evolution which, though having applications, are often do not find economic support.

Pattern finding

Eleanor Ormerod, an unexpected influence in the rise of economic entomology in India

The pattern finding phase when reached allows a field to become professional - with paid services offered by practitioners. It is the phase in which science flexes its muscle, specialists gain social status, and are able to make livelihoods out of their interest. Lefroy (1904) cites economic entomology as starting with E.C. Cotes [Cotes' career in entomology was short, after marrying the famous Canadian journalist Sara Duncan in 1889 he too moved to writing] in the Indian Museum in 1888. But he surprisingly does not mention any earlier attempts, and one finds that Edward Balfour, that encyclopaedic-surgeon of Madras collated a list of insect pests in 1887 and drew inspiration from Eleanor Ormerod who hints at the idea of getting government support, noting that it would cost very little given that she herself worked with no remuneration to provide a service for agriculture in England. Her letters were also forwarded to the Secretary of State for India and it is quite possible that Cotes' appointment was a result.

As can be imagined, economics, society, and the way science is supported - royal patronage, family, state, "free markets", crowd-sourcing, or mixes of these - impact the way an individual or a field progresses. Entomology was among the first fields of zoology that managed to gain economic value with the possibility of paid employment. David Lack, who later became an influential ornithologist, was wisely guided by his father to pursue entomology as it was the only field of zoology where jobs existed. Lack however found his apprenticeship (in Germany, 1929!) involving pinning specimens "extremely boring".

Indian reflections on the history of entomology

Kunhikannan died at the rather young age of 47

A rather interesting analysis of Indian science is made by the first native Indian entomologist to work with the official title of "entomologist" in the state of Mysore - K. Kunhikannan. Kunhikannan was deputed to pursue a Ph.D. at Stanford (for some unknown reason many of the pre-Independence Indian entomologists trained in Stanford rather than England - see postscript) through his superior Leslie Coleman. At Stanford, Kunhikannan gave a talk on Science in India. He noted in his 1923 talk :

In the field of natural sciences the Hindus did not make any progress. The classifications of animals and plants are very crude. It seems to me possible that this singular lack of interest in this branch of knowledge was due to the love of animal life. It is difficult for Westerners to realise how deep it is among Indians. The observant traveller will come across people trailing sugar as they walk along streets so that ants may have a supply, and there are priests in certain sects who veil that face while reading sacred books that they may avoid drawing in with their breath and killing any small unwary insects. [Note: Salim Ali expressed a similar view ]

He then examines science sponsored by state institutions, by universities and then by individuals. About the last he writes:

Though I deal with it last it is the first in importance. Under it has to be included all the work done by individuals who are not in Government employment or who being government servants devote their leisure hours to science. A number of missionaries come under this category. They have done considerable work mainly in the natural sciences. There are also medical men who devote their leisure hours to science. The discovery of the transmission of malaria was made not during the course of Government work. These men have not received much encouragement for research or reward for research, but they deserve the highest praise., European officials in other walks of life have made signal contributions to science. The fascinating volumes of E. H. Aitken and Douglas Dewar are the result of observations made in the field of natural history in the course of official duties. Men like these have formed themselves into an association, and a journal is published by the Bombay Natural History Association[sic], in which valuable observations are recorded from time to time. That publication has been running for over a quarter of a century, and its volumes are a mine of interesting information with regard to the natural history of India.

This then is a brief survey of the work done in India. As you will see it is very little, regard being had to the extent of the country and the size of her population. I have tried to explain why Indians' contribution is as yet so little, how education has been defective and how opportunities have been few. Men do not go after scientific research when reward is so little and facilities so few. But there are those who will say that science must be pursued for its own sake. That view is narrow and does not take into account the origin and course of scientific research. Men began to pursue science for the sake of material progress. The Arab alchemists started chemistry in the hope of discovering a method of making gold. So it has been all along and even now in the 20th century the cry is often heard that scientific research is pursued with too little regard for its immediate usefulness to man. The passion for science for its own sake has developed largely as a result of the enormous growth of each of the sciences beyond the grasp of individual minds so that a division between pure and applied science has become necessary. The charge therefore that Indians have failed to pursue science for its own sake is not justified. Science flourishes where the application of its results makes possible the advancement of the individual and the community as a whole. It requires a leisured class free from anxieties of obtaining livelihood or capable of appreciating the value of scientific work. Such a class does not exist in India. The leisured classes in India are not yet educated sufficiently to honour scientific men.

It is interesting that leisure is noted as important for scientific advance. Edward Balfour, mentioned earlier, also made a similar comment that Indians were "too close to subsistence to reflect accurately on their environment!"  (apparently in The Vydian and the Hakim, what do they know of medicine? (1875) which unfortunately is not available online)

Kunhikannan may be among the few Indian scientists who dabbled in cultural history, and political theorizing. He wrote two rather interesting books The West (1927) and A Civilization at Bay (1931, posthumously published) which defended Indian cultural norms while also suggesting areas for reform. While reading these works one has to remind oneself that he was working under and with Europeans and may not have been able to have many conversations on such topics with Indians. An anonymous writer who penned the memoir of his life in his posthumous work notes that he was reserved and had only a small number of people to talk to outside of his professional work.

Entomologists meeting at Pusa in 1919 Third row: C.C. Ghosh (assistant entomologist), Ram Saran ("field man"), Gupta, P.V. Isaac, Y. Ramachandra Rao, Afzal Husain, Ojha, A. Haq Second row: M. Zaharuddin, C.S. Misra, D. Naoroji, Harchand Singh, G.R. Dutt (Personal Assistant to the Imperial Entomologist), E.S. David (Entomological Assistant, United Provinces), K. Kunhi Kannan, Ramrao S. Kasergode (Assistant Professor of Entomology, Poona), J.L.Khare (lecturer in entomology, Nagpur), T.N. Jhaveri (assistant entomologist, Bombay), V.G.Deshpande, R. Madhavan Pillai (Entomological Assistant, Travancore), Patel, Ahmad Mujtaba (head fieldman), P.C. Sen First row: Capt. Froilano de Mello, W Robertson-Brown (agricultural officer, NWFP), S. Higginbotham, C.M. Inglis, C.F.C. Beeson, Dr Lewis Henry Gough (entomologist in Egypt), Bainbrigge Fletcher, Bentley, Senior-White, T.V. Rama Krishna Ayyar, C.M. Hutchinson, Andrews, H.L.Dutt

Enotmologists meeting at Pusa in 1923 Fifth row (standing) Mukerjee, G.D.Ojha, Bashir, Torabaz Khan, D.P. Singh Fourth row (standing) M.O.T. Iyengar (a malariologist), R.N. Singh, S. Sultan Ahmad, G.D. Misra, Sharma, Ahmad Mujtaba, Mohammad Shaffi Third row (standing) Rao Sahib Y Rama Chandra Rao, D Naoroji, G.R.Dutt, Rai Bahadur C.S. Misra, SCJ Bennett (bacteriologist, Muktesar), P.V. Isaac, T.M. Timoney, Harchand Singh, S.K.Sen Second row (seated) Mr M. Afzal Husain, Major RWG Hingston, Dr C F C Beeson, T. Bainbrigge Fletcher, P.B. Richards, J.T. Edwards, Major J.A. Sinton First row (seated) Rai Sahib PN Das, B B Bose, Ram Saran, R.V. Pillai, M.B. Menon, V.R. Phadke (veterinary college, Bombay)

Note: As usual, these notes are spin-offs from researching and writing Wikipedia entries, in this case on several pioneering Indian entomologists. It is remarkable that even some people in high offices, such as P.V. Isaac, the last Imperial Entomologist, and grandfather of noted writer Arundhati Roy, are largely unknown (except as the near-fictional Pappachi in Roy's God of Small Things)


Further reading

• Balfour, Edward (1887). The agricultural pests of India, and of eastern and southern Asia, vegetable and animal, injurious to man and his products. London: Bernard Quaritch.
• Ball, V. 1885. On the identification of the animals and plants of India which were known to early Greek authors. The Indian Antiquary. 14:274-287, 303-311, 334-341
• Barnard, Peter C. (2018). Bat-Fowlers, Pooters and Cyanide Jars: a Historical Overview of Insect Collecting and Preservation in MacGregor, A. (Ed.).  Naturalists in the Field . Brill.
• Dave, KN (1950) Lac and the lac insect in the Atharva veda. Int Acad Ind Cult Nagpur, 16 pp. [Dave incidentally, is also the translator and interpreter of another problematic work on ornithological knowledge in ancient Indian literature] 
• Essig, E.O. (1931) A history of entomology. New York: The Macmillan Company.
• Farber, P.L. (1976). The type-concept in zoology during the first half of the nineteenth century. Journal of the History of Biology 9(1):93–119.  
• Hewitt, C. Gordon (1916). A review of applied entomology in the British Empire. Annals of the Entomological Society of America. 9(1):1–33.
• Howard, L.O. (1930). A history of applied entomology (Somewhat Anecdotal). Smithsonian Institution. Publication 3065.
• Husain, Mohamad Afzal (1938). Entomology in India, past, present and future. Current Science 6(8):422-424. [This is a summary, for the full address see - Husain, M. Afzal (1939). "Entomology in India: Past, Present and Future."  Proceedings of the Twenty-fifth Indian Science Congress, Calcutta, 1938. pp. 201–246]
• Lefroy, Maxwell (1904). Historical summary in Report of the Entomologist to the Government of India.
• Lienhard, S. (1978) On the meaning and use of the word indragopa. Indologica Taurinensia 6:177-188.
• Lockwood, J.A. (2012) Insects as weapons of war, terror, and torture. Annual Review of Entomology 57:205-227.
• Mahdihassan, S. (1986). Lac and its decolourization by orpiment as traced to Babylon. Indian Journal of History of Science 21(2):187-192.
• Melillo, E. D. (2013). Global Entomologies: Insects, Empires, and the “Synthetic Age” in World History. Past & Present, 223(1):233–270. doi:10.1093/pastj/gtt026
• Rao, H. Srinivasa (1957) History of our knowledge of the Indian fauna through the ages. Journal of the Bombay Natural History Society 54:251-280.
• Rao, B.R. Subba (1983). Systematic entomology in India - past, present and future. Current Science 52(21):997-1000.
• Romero, D.B. (2007). El díkairon en la obra Indika de Ctesias de Cnido. Propuesta de identificación. Emerita 75(2):255-272.
• Roy, Rohan Deb (2017). Malarial Subjects. Cambridge University Press. [Open-Access]
• Roy, Rohan Deb (2013). Quinine, mosquitoes and empire: reassembling malaria in British India, 1890–1910, South Asian History and Culture, 4(1):65-86. doi:10.1080/19472498.2012.750457
• Service, M. W. (1978). Review Article1: A Short History of Early Medical Entomology. Journal of Medical Entomology, 14(6):603–626. doi:10.1093/jmedent/14.6.603 
• Smith, Ray F.; Mittler, T.E.; Smith, Carroll N. (1973). History of Entomology. Annual Reviews Inc. ISBN 0824321017.
• Sorensen, Conner (1988). The Rise of Government Sponsored Applied Entomology, 1840-1870. Agricultural History 62(2):98-115. 
• Sutter, P. S. (2007). Nature’s Agents or Agents of Empire? Isis, 98(4):724–754.

An index to entomologists who worked in India or described a significant number of species from India - with links to Wikipedia (where possible - the gaps in coverage of entomologists in general are too many)
(woefully incomplete - feel free to let me know of additional candidates)

Carl Linnaeus - Johan Christian Fabricius - Edward Donovan - John Gerard Koenig - John Obadiah Westwood - Frederick William Hope - George Alexander James Rothney - Thomas de Grey Walsingham - Henry John Elwes - Victor Motschulsky - Charles Swinhoe - John William Yerbury - Edward Yerbury Watson - Peter Cameron - Charles George Nurse - H.C. Tytler - Arthur Henry Eyre Mosse - W.H. Evans - Frederic Moore - John Henry Leech - Charles Augustus de Niceville - Thomas Nelson Annandale - R.C. Wroughton -  T.R.D. Bell - Francis Buchanan-Hamilton - James Wood-Mason - Frederic Charles Fraser  - R.W. Hingston - Auguste Forel - James Davidson - E.H. Aitken -  O.C. Ollenbach - Frank Hannyngton - Martin Ephraim Mosley - Hamilton J. Druce  - Thomas Vincent Campbell - Gilbert Edward James Nixon - Malcolm Cameron - G.F. Hampson - Martin Jacoby - W.F. Kirby - W.L. Distant -  C.T. Bingham - G.J. Arrow - Claude Morley - Malcolm Burr - Samarendra Maulik - Guy Marshall

 

Edward Percy Stebbing - T.B. Fletcher - Edward Ernest Green - E.C. Cotes - Harold Maxwell Lefroy - Frank Milburn Howlett - S.R. Christophers - Leslie C. Coleman - T.V. Ramakrishna Ayyar - Yelsetti Ramachandra Rao - Magadi Puttarudriah - Hem Singh Pruthi - Shyam Sunder Lal Pradhan - James Molesworth Gardner - Vakittur Prabhakar Rao - D.N. Raychoudhary - C.F.W. Muesebeck  - Mithan Lal Roonwal - Ennapada S. Narayanan - M.S. Mani - T.N. Ananthakrishnan - Muhammad Afzal Husain

Not included by Rao -   F.H. Gravely - P.V. Isaac - M. Afzal Husain - A.D. Imms - C.F.C. Beeson

 - C. Brooke Worth - Kumar Krishna - M.O.T. Iyengar - K. Kunhikannan


PS: Thanks to Prof C.A. Viraktamath, I became aware of a new book-  Gunathilagaraj, K.; Chitra, N.; Kuttalam, S.; Ramaraju, K. (2018). Dr. T.V. Ramakrishna Ayyar: The Entomologist. Coimbatore: Tamil Nadu Agricultural University. - this suggests that TVRA went to Stanford at the suggestion of Kunhikannan.

Extract from the Education booklet case study, written by Wikimedia UK and University of Edinburgh.

Earlier this year we produced a booklet with the University of Edinburgh, bringing together a collection of case studies from across the UK in order to provide insight into the use of the Wikimedia projects in education. It is our belief that the Wikimedia projects are a valuable tool for education, and that engagement with those projects is an activity which enriches the student experience as much as it does the open web itself. As such we have a number of education projects, and have managed to introduce Wikimedia teaching as a part of the Welsh baccalaureate. You can find what we’ve blogged about these projects in the education tag.

Educators worldwide are using Wikimedia in the curriculum – teaching students key skills in information literacy, collaboration, writing as public outreach, information synthesis, source evaluation and data science. Engaging with projects like Wikipedia – particularly through becoming a contributor – enables learners to understand, navigate and critically evaluate information as well as develop an appreciation for the role and importance of open education. Once published, material produced by students becomes immediately accessible by a global audience, giving students the satisfaction of knowing that their work can be seen by many more people than just their tutor.

As individuals working in the open web in the twenty-first century it is incumbent upon us to embrace innovative learning, embedding into our practice those tools which equip our students to work collaboratively, be skilled digitally, and think critically.

Of our 13 examples, 12 pertain to Higher Education, and one to Secondary; but although this work has thus far been more common in Universities than schools or colleges of Further Education, it is far from being restricted solely to them. This resource has been designed for anyone involved in education, and will be of particular interest to those teachers, lecturers and learning technologists involved in open pedagogy and course design, or who have an interest in innovative learning, working on the open web, co-creation, collaborative working, or digital skills.

Feedback from both students and course leaders, at the University of Edinburgh and beyond, has consistently highlighted:

• Student-led creation of academic quality content, available to be shared and used by wide audiences
• Students and course leaders having the opportunity to examine their subject area reflectively through a global, publicly engaged perspective
• Students having the opportunity to learn and practice beginner-level coding skills and increase their digital competencies

Wikimedia and Skills development

The Wikimedia projects are more than just Wikipedia.  There are 13 projects in all, four which are of particular interest here: Wikipedia, Wikidata, Wiki Commons, and Wikibooks.  

Wikimedia UK has produced a report mapping engagement with the projects to existing digital skills frameworks in the UK, which can be read on Wikimedia UK’s website. and a report on The Potentials of Wikimedia Projects in Digital, Information and Data Literacy Development in the UK context. 

The skills which can be enhanced through engagement with the Wikimedia Projects include:

Wikipedia  the online encyclopedia

• Computer and internet literacy, from opening an account to searching and critically evaluating information online.
• Creating, preparing (digitizing, editing, converting), uploading, categorising, translating information and digital content
• Collaboration, communication and consensus building in an online environment
• Understanding reliable, verifiable sources, licences, consents, and copyright
• Encyclopedic writing in the public domain, using citation softwares and referencing

WikiData an open database and central storage for structured data

• Understanding data concepts, data types, data functions and data characteristics
• Importing, exporting, linking, reusing, and combining datasets
• Understanding of Creative Commons database rights 
• Engaging with the development of data models, exploring and visualising your data 
• Collaborative data management 

Wiki Commons a host of media files and their metadata

• Understanding of free digital file types and formats
• Understanding organisation of information and discoverability
• Understanding of the educational value of different types of content
• Content reuse skills, including editing and improving images

Wikibooks a collaborative, instructional non-fiction book authoring website

• Wring in Wikitext or in a combination of Wikitext, HTML, and CSS 
• Content creation, collaborative editing, translation
• Editing skills (like spelling and grammar or formatting errors) 
• Understanding of licensing (GFDL and Creative Commons)

Here’s one of the case studies included in the booklet…

Life Sciences BSc degrees, Science Communication, Imperial College London

Final year Biochemistry and Biological Sciences BSc students at Imperial College London selected and improved Wikipedia articles within their Science Communication module by adding content to existing pages, including adding their own illustrations.

Course leaders: Prof. Stephen Curry, professor of Structural Biology, and Dr. Steven Cook, Principal Teaching Fellow in the Department of Life Sciences.

Class size: 30 students.

Course duration: 1 academic term, featuring a 3-hour workshop introducing Wikimedia, Creative Commons, and practising Wiki mark-up language.

Learning outcomes

• Developing writing skills suited for a public audience.
• Increasing critical thinking, information and digital literacy.
• Introducing basic illustration and graphic design skills.
• Introducing collaborative writing, useful for future academic and work-based projects.

Further support and resources used

• Wikimedia UK’s Programmes team.
• The Wikipedia Manual of Style guidelines.
• Science communication and illustration workshops run by staff on the Science Communication module.
• Wikimedia Commons and the RCSB Protein Data Bank.
• User:Polypompholyx’s Wikipedia page includes guidance for students.

Impact beyond the classroom

• 100 articles improved since 2012.
• Several illustrations and photographs were created and uploaded to Wikipedia pages to support the relevant compound’s Wikipedia page.
• Contributed to the growing Wiki culture and community within the University.

“There are plenty of incomplete and missing articles on Wikipedia, and it would be great to get students involved in editing articles much earlier in their Careers.”

“The articles have to be on a scientific topic, and they typically choose life science topics, as that is their expertise (biology and biochemistry students). Some articles are created from scratch, others take existing articles and improve them. This is typically by rewriting the text to make it clearer, more complete and more up to date. Most articles end up with new sections, updated references, and additional media: either from Commons, or media they create and CC license themselves.” Dr. Steven Cook, Course Leader

For more of the education booklet case studies, take a look at the free digital copy here. For more information on our education projects, follow the blog tag, sign up for our newsletter, or get in touch with us. To support Wikimedia UK projects like this one, please consider donating or becoming a member today.

06/10/2020-12/10/2020

Mapping

• GIScience Heidelberg and HeiGIT have created a new land use map, initially for all the EU member states, by combining satellite images from Sentinel with OpenStreetMap using machine learning. It is available on OSMlanduse.org. The quality of the new version of OSMlanduse is being validated in an online campaign. You can participate in the Landsense Mapathon. There are different topics, such as nature, urban, agriculture and expert. The validation campaign is supported within the framework of the EU regions week.
• The UK quarterly project for Q4 has been selected as defibrillators.
• Sarah Hoffmann (aka lonvia) informs us, in her blog post, how Nominatim can be used to search for addresses and how Nominatim also now uses the addr:* tags recorded in OSM to determine addresses precisely.
• Diego Cruz proposed the new tag landuse=dehesa to describe a type of man-made land use that has existed for centuries in the Southwestern quarter of the Iberian Peninsula and which is a sparsely-treed forest (Quercus species) in which the ground is cultivated or used as pasture for grazing animals.
• Voting started on 12 October on Andrew Harvey’s proposed tag shelter_type=rock_shelter to mark the difference between the already existing natural=cave_entrance and a shallow cave-like opening at the base of a bluff or cliff, which may be used to shelter from the weather.

Community

• k_zoar is a Japanese mapper and lets us take part in reviewing his 10 years of contributing to OSM. For years, he was one of only two mappers to publish the Japanese version of weeklyOSM.
• Thomas Skowron has submitted an interim report for his OSMF Microgrants project focused on the OpenStreetMap Calendar, documenting his progress at the halfway mark.
• Richard Fairhurst complained about an undercover change of the Mapbox GL licence.

OpenStreetMap Foundation

• The minutes of the OSMF virtual board meeting on 2 and 3 October have been published. The minutes of the agenda item on a possible move to the European Union, where the OSM database enjoys legal protection, have also been published.
• Ilya Zverev shared > his thoughts about recent large-scale payments made by OSMF Board.
• Simon Poole has left the OMSF’s Licensing Working Group. The team at weeklyOSM would like to thank Simon for his hard work over the years.

Local chapter news

• Minh Nguyen wrote about OpenStreetMap US becoming a local chapter of the OSMF.

Events

• There will be a GIS track at the 18th International Conference on Information Systems for Crisis Response and Management (ISCRAM 2021). You can submit a full paper until 6 December, while short and practitioner papers can be submitted until 31 January 2021.
• The next CH Open Business Lunch will take > place in Basel 26 November, from 11 AM with Stefan Keller and the topic ‘The innovation potential of OpenStreetMap and Wikidata/Wikipedia/Wikimedia Commons’. Language: , Slides: .
• Stefan Keller (Switzerland) reports > that this year’s DINAcon 2020 will take place on Friday 23 October 2020. (This time, as the name suggests, online and not at Well7 in Bern.)
• The keynote speakers for SotM Japan 2020 > , which will be held online on 7 November, have been announced . And registration has also started .
• The programme > for the FOSS4G Japan 2020 Online core day to be held on 8 November has been announced .
• Speakers from HOT, YouthMappers, Facebook, and Microsoft are coming together at the UN World Data Forum on 19 October, 4:00 PM UTC. Find the programme here, and register for your free participation in the online event.

Humanitarian OSM

• In collaboration with the Deltares institute and with funding from German International Cooperation Agency, OpenMap Development Tanzania was able to collect accurate and precise river cross-section surveys using an innovative, low-cost technique. This information will help in improving existing flood risk models and prevention.

Maps

• Hartmut Holzgräfe was happy to report that his MapOSMatic instance has rendered 130,000 maps and also announced email conversion and style upgrades.
• Curvature is a programme that analyses the geometry of OSM roads and generates a map of the most twisty roads, colour-coded by how many curves they have.
• Bloomberg described a building resembling Taiwan’s Presidential Office found in the military training base of Zurohe, which is in Inner Mongolia, China. Supaplex writes that you could compare the outline of both buildings on OpenStreetMap.

Open Data

• [1] 15 projects have made it on the DINAcon Awards 2020 shortlist > . Winners in the five categories will be honoured at the Digital Awards Ceremony on 23 October at the online held Conference for Digital Sustainability (DINAcon, register here). Among the finalists are the NeTEx Converter plugin for JOSM, the geo-admin map viewer, and a traffic flow > visualisation from Zurich.
• The Norwegian Mapping Authority ‘Kartverket’ was awarded > ‘National Geospatial Agency of The Year’ by Geospatial Media in the Netherlands. The jury especially noted its international efforts in humanitarian projects, the UN and sea charts. Kartverket has had a significant impact in OSM in Norway due to the large quantity of open data, including high quality orthophotos, which has been most useful, along with import projects related to land cover and road networks.

Licences

• Nuno Caldeira complained about the incorrect attribution of OpenStreetMap by Mapbox.

Software

• CyclOSM has released its new 0.3.7 version, including many rendering improvements.
• 15 years ago, Immanuel Scholz proudly announced a beta for JOSM, his Java OpenStreetMap Editor. At that time, the software was only capable of reading and saving a local GPX-file, but already had a homepage, wiki and bugtracker!
• A new version of MapComplete has been released by Pietervdvn. This simple editor now has an easy-to-use opening hours selection and a richer selection of background options. In order to celebrate this, an editable map with shops was created through which you can send opening hours directly to OSM. Furthermore, we remind everyone that anyone can easily make their own custom preset (or theme). Yopaseopor figured out how to and has already created ten such themes, which can be found on his wiki.

Did you know …

• … that the website ‘Map of the Week’ recently featured the best map-related manhole covers?
• … the twitch channel of Martijn van Exel as the curious mapper? Martijn is a former member of the OSM US and OSMF Board of Directors and the author of MapRoulette.

OSM in the media

• The Daily Star featured female mappers from YouthMappers Dhaka University Chapter and YouthMappers Regional Ambassador Maliha Mohiuddin to recognise inclusive mapping on the occasion of International Day of the Girl Child.
• The Information reported on an antitrust battle against Google. ‘Credit for that goes to Mapbox’ and further ‘A congressional report on Tuesday, which made antitrust claims against four major tech companies, included a little-noticed allegation that Google Maps abused its market power and harmed its customers’ by not allowing apps using Google’s location data and other providers’ maps or geographical services at the same time.

Other “geo” things

• The European Commission has opened a position for a trainee to explore synergies between INSPIRE and the OpenStreetMap data ecosystems and assess the potential of OSM for the creation and updating of identified high-value datasets.
• The publishers of the decorative atlas Mad Maps have also published a serious game, teaching the basic elements of cartography. You can download it for Windows, Mac and Linux, or play online – but unfortunately it is only available in French.
• Search engine DuckDuckGo now allows route planning in their map service, based on maps from Apple’s Mapkit JS framework. As Golem.de reports > , the location query should be particularly secure because location data is transferred separately from personal information and is deleted after the query.
• dmontagne presented > the results of their effort to georeference and superimpose historical maps on to current ones using the French platform Navigae.

Upcoming Events

Where	What	When	Country
Cobb Virtual Academy	OSMUK AGM plus presentations	2020-10-17
Cologne Bonn Airport	132. Bonner OSM-Stammtisch (Online)	2020-10-20
Lüneburg	Lüneburger Mappertreffen	2020-10-20
Berlin	OSM-Verkehrswende #16 (Online)	2020-10-20
Nottingham	Nottingham pub meetup	2020-10-20
Lyon	Rencontre mensuelle pour tous	2020-10-20
Žilina	Missing Maps Mapathon Žilina #9 (Online)	2020-10-22
Bremen	Bremer Stammtisch	2020-10-26
Arlon	Réunion des contributeurs OpenStreetMap	2020-10-26
Salt Lake City / Virtual	OpenStreetMap Utah Map Night	2020-10-27
Düsseldorf	Düsseldorfer OSM-Stammtisch	2020-10-28
Salt Lake City / Virtual	OpenStreetMap Utah Map Night	2020-10-29
London	Missing Maps London Mapathon	2020-11-03
Stuttgart	Stuttgarter Stammtisch (online)	2020-11-04
Dresden	Dresdner OSM-Stammtisch	2020-11-05
Online	2020 Pista ng Mapa	2020-11-13-2020-11-27
Online	FOSS4G SotM Oceania 2020	2020-11-20

Note: If you like to see your event here, please put it into the calendar. Only data which is there, will appear in weeklyOSM. Please check your event in our public calendar preview and correct it, where appropriate.

This weeklyOSM was produced by AnisKoutsi, Lejun, MatthiasMatthias, Nordpfeil, NunoMASAzevedo, Polyglot, Rogehm, Guillaume Rischard (Stereo), TheSwavu, YoViajo, alesarrett, derFred, k_zoar, osmapman, richter_fn.

Amarílis Corrêa is a librarian at the Faculty of Architecture and Urbanism of the University of São Paulo. She enrolled in Wiki Education’s introductory Wikidata course to learn more about how to apply linked data practices to her work.

Before talking about my experience with Wiki Education’s Wikidata Institute course, allow me to present you a brief context of how I discovered Wikidata and its potential to cultural heritage and scientific collections held by libraries and the enriching contributions librarians can bring.

At the beginning of 2020, one of my assignments was to bring back to life a referential database of articles (published in Brazilian magazines and academic journals) that had crashed a couple of years ago due to technological and hardware failure. This would be the chance to convert the MARC records into more searchable, visible, and connected to other collections. However, what were the options?

I’m a researcher on digital preservation, so I had heard of linked data and linked open data for this purpose, but I hadn’t dug into that until the COVID-19 pandemic crisis arrived in Brazil in March and I started working from home. Many conferences happened virtually – like LIBER2020 and LD4, much easier to attend especially when free of charge – and I had the chance to join meetings and workshops, to meet professionals from other countries, and to get to know their projects, listen to their experiences, challenges, and accomplishments. In the course of a week or two, linked open data appeared several times, more than ever before, in talks with Brazilian colleagues and from other countries. One of the approaches to Wikidata came from getting to know one of the coordinators of Wiki Movement Brazil User Group through a close librarian at the university.

When I registered for the Wikidata Institute-September course I had a vague idea of what Wikidata was, I had had the chance to add a few references to statements, and I had experienced some frustrating attempts to run queries. Just by reading the first article suggested by Will Kent – one of our very patient and attentive instructors, the other was Ian Ramjohn – and doing the first assignments I realized how broad Wikidata is: it aggregates from fantastic creatures and imaginary worlds to asteroids, species of flowers, rock bands, historic buildings, scientific articles, calendar years, and so on. It can really be the place to represent as structured data everything that exists.

During the course, one of the most popular subjects on our meetings was the way of representing items. As librarians and cataloguers many of us were concerned about standards and data models: how is the best way to describe this or that? What values or references are most appropriate? Is there a recommended good practice? We also had a classmate always raising questions about semantics because it’s her expertise and she saw different values being used as synonyms. The one-hour meetings weren’t usually enough for debating, commenting on our experiments during the week, presenting doubts, and receiving new concepts and tools demos from Will’s presentations. That’s why the Slack channel was always so hectic.

A three-week course about Wikidata is a good introduction, because it’s a long learning curve until one can feel confident in editing and exploring the potential offered by Wikidata. Even though instance of (P31) still makes me think a lot of the best value to use – one more general or more specific, or several values – and queries represent quite a challenge, I guess after this course I feel I can guide other beginners through the basics of Wikidata and to plan how to adopt it as the environment to share library collections as data.

Besides the practice of editing (that makes time fly because a “simple” statement leads to another item that presents another statement that may need edition or even the creation of a new item), there are many tools to be familiar with, of course you don’t need to use them all; nevertheless, some of them can be useful to create items, to identify languages missing in descriptions and/or labels, to create data visualization, to present an item in a more user-friendly interface like Reasonator. There are also many WikiProjects to check when looking for those that may be related to your professional practice (or personal interest), in which you can participate as well as adapt to your institution or collection.

My first use of the knowledge developed will be working on the GLAM-Wiki I’m helping to implement for libraries of the University of São Paulo (GLAM Bibliotecas da USP), aiming to open data of scientific and artistic productions of the scholars, bibliographic data of the journals published by the university, and its cultural and scientific heritage collections. I intend to stay in touch and keep learning through the conferences and collaborative spaces recommended during the course and others (like IFLA Wikidata Working Group), as well as to share the achievements of this GLAM.

Undoubtedly, I’ll give credit to this great experience I had thanks to Wikidata Institute, the instructors Will and Ian, and all the classmates.

Interested in taking a course like the one Amarílis took? Visit wikiedu.org/wikidata to see current course offerings.

lingthusiasm:

Lingthusiasm Episode 49: How translators approach a text

Before even starting to translate a work, a translator needs to make several important macro-level decisions, such as whether to more closely follow the literal structure of the text or to adapt more freely, especially if the original text does things that are unfamiliar to readers in the destination language but would be familiar to readers in the original language. 

In this episode of Lingthusiasm, your hosts Gretchen McCulloch and Lauren Gawne get enthusiastic about the relationship of the translator and the text. We talk about the new, updated translation of Beowulf by Maria Dahvana Headley (affectionately known as the “bro” translation), reading the Tale of Genji in multiple translations, translating conlangs in fiction, and mistranslation on the Scots Wikipedia. 

Announcements

We’re coming up on Lingthusiasm’s fourth anniversary! In celebration, we’re asking you to help people who would totally enjoy listening to fun conversations about linguistics, they just don’t realize it exists yet! Most people still find podcasts through word of mouth, and we’ve seen a significant bump in listens each November when we ask you to help share the show, so we know this works. If you tag us @lingthusiasm on social media in your recommendation post, we will like/retweet/reshare/thank you as appropriate, or if you send a recommendation to a specific person, we won’t know about it but you can still feel a warm glow of satisfaction at helping out (and feel free to still tell us about it on social media if you’d like to be thanked!). Trying to think of what to say? One option is to pick a particular episode that you liked and share a link to that. 

This month’s bonus episode was about honorifics, words like titles and forms of “you” that express when you’re trying to be extra polite to someone (and which can also be subverted to be rude or intimate). Get access to this and 43 other bonus episodes at patreon.com/lingthusiasm.

This is also a good time to start thinking about linguistics merch and other potential gift ideas (paperback copies of Because Internet, anyone?), in time for them to arrive via the internet, if you’re ordering for the holiday season. Check out the Lingthusiasm merch store at lingthusiasm.com/merch.  

Here are the links mentioned in this episode:

• Lingthusiasm Episode 18: Translating the untranslatable
• Beowulf, translation by Maria Dahvana Headley
• A “Beowulf” for Our Moment (New Yorker)
• Gretchen reads Beowulf (twitter thread)
• The Sensualist: What makes “The Tale of Genji” so seductive (New Yorker)
• Shadowscent, by P.M Freestone
• How I made the Aramteskan language (Superlinguo)
• Scots Wikipedia (Wikipedia article)
• Wikipedia has a Google Translate problem (The Verge)
• Gretchen’s twitter thread about Scots Wikipedia
  

You can listen to this episode via Lingthusiasm.com, Soundcloud, RSS, Apple Podcasts/iTunes, Spotify, YouTube, or wherever you get your podcasts. You can also download an mp3 via the Soundcloud page for offline listening, and stay tuned for a transcript of this episode on the Lingthusiasm website. To receive an email whenever a new episode drops, sign up for the Lingthusiasm mailing list.

You can help keep Lingthusiasm advertising-free by supporting our Patreon. Being a patron gives you access to bonus content and lets you help decide on Lingthusiasm topics.

Lingthusiasm is on Facebook, Tumblr, Instagram, Pinterest, and Twitter.

Email us at contact [at] lingthusiasm [dot] com

Gretchen is on Twitter as @GretchenAMcC and blogs at All Things Linguistic.

Lauren is on Twitter as @superlinguo and blogs at Superlinguo.

Lingthusiasm is created by Gretchen McCulloch and Lauren Gawne. Our senior producer is Claire Gawne, our editorial producer is Sarah Dopierala, and our music is ‘Ancient City’ by The Triangles

When I first created Wikipedia back in 2001, the internet was a very different place. Only seven percent of people worldwide had a broadband connection, and more people spent time building personal websites than getting their news online. I knew what I wanted to create: a free encyclopedia, written by volunteers, for everyone in the world. But I wasn’t sure I knew how to do it.

I always joke that I’m a pathological optimist, so I was excited that this was almost a ridiculously big concept. And it worked. All these years later, the Wikimedia community of volunteers has created the largest collection of open knowledge in human history.

Today, Wikipedia has over 50 million articles (51.6 million to be precise — we love precision as Wikimedians) written by more than 250,000 volunteer editors around the world. This grand experiment has expanded in ways that I never thought possible. Wikipedia, Wikidata, Wiktionary and our other free knowledge projects host information on virtually every topic, and invite everyone to share what they know.

“All these years later, the Wikimedia community of volunteers has created the largest collection of open knowledge in human history.”

These projects have become trusted sources of knowledge, from who won the football match last week to understanding how a global pandemic is shaping our lives. All of this information — from the types of trains in India to the most popular British children’s books — is made possible by volunteer editors. Volunteers who contribute their time, research, writing skills, and more to make sure everyone has access to trusted information.

Oftentimes, being a volunteer Wikipedia editor is an invisible role. Few people will look at the talk page for an article, to learn more about the people who built it. But volunteers keep doing it anyway, because they believe in free knowledge, and they believe in contributing something to the benefit of the collective good.

The Wikimedian of the Year award is one small way I can say thank you, and recognize the time, effort, and resources it takes to keep Wikimedia projects up-to-date, neutral, and reliable. It is how I celebrate those volunteers who go above and beyond to fulfill our mission of free knowledge for the world.

I first started the Wikimedian of the Year award in 2011, in order to appreciate one of our standout volunteers for their achievements and their work on behalf of free knowledge. At that time it felt like a small thing to do at our annual conference — and over the years it has gotten bigger and bigger as people outside our movement are inspired by the individual stories behind the award.

I’m excited to announce that this year’s Wikimedian of the year is Sandister Tei, user: Sandiooses. Sandister helped pioneer the development of our volunteer communities in sub-Saharan Africa. She was one of the founding members of the Wikimedia Ghana User Group, the local Wikimedia affiliate group in Ghana, and has been very involved with the community there. This year, as the pandemic forced the user group to cancel in person events and gatherings, Sandister helped her community stay connected and informed. Through research and local sources, she contributed heavily to the Wikipedia articles about the pandemic’s effects in Ghana, ensuring the public record included Ghana in the story of how the COVID-19 pandemic is shaping the world.

“In a community dedicated to free knowledge, Wikimedians of the Year are the closest things we have to celebrity.”

A few weeks ago, I joined a Zoom call to surprise Sandister and tell her about the award. It was the first time we had met, in what passes for “in person” this year. She was shocked by the news, and it was incredibly fun to see her reaction as she learned about receiving this award.

In a community dedicated to free knowledge, Wikimedians of the Year are the closest things we have to celebrity. They are sometimes prolific editors; other times they are movement organizers, photographers, and knowledge activists. They create communities, initiate partnerships, welcome new people, and commit themselves to the work of building the sum of all knowledge. They usually come to my attention because they are recognized by their peers for their contributions.

But the Wikimedian of the Year is about more than an award — it’s a recognition of the role that volunteers play in this huge, sprawling global movement. There would be no Wikipedia, no Commons, no Wikidata without our volunteers. They write the words you read, upload the images you see; they build the knowledge that informs our world. The Wikimedian of the Year is a celebration of our volunteers because they are what make our projects and this movement possible.

As Wikipedia approaches its 20th birthday this coming January, the world looks different than it did in 2001. In many ways, it’s harder to be a Wikimedian. Misinformation is spreading at unprecedented rates, and there are fewer and fewer neutral places on the internet. It is because of people like Sandister and other leaders in the Wikimedia movement that Wikipedia will stay useful and relevant for years to come. It makes me incredibly excited for what the next 20 years for Wikipedia will hold, and who else will join us along the way.

“The Wikimedian of the Year is about more than an award — it’s a recognition of the role that volunteers play in this huge, sprawling global movement.”

In any other year, I would join Wikimedians from around the world at our international conference, Wikimania, to celebrate this amazing news. While we can’t be together in person this year, I’m thrilled to recognize Sandister in a virtual celebration. And here’s to hoping I will see you in person next year!

Learn more about Sandister and her work here.

The 2020 elections are fast approaching in the United States, and as people prepare to vote (often from home, by mail) they’re looking for information that can help them make up their minds.

At first glance that seems surprising: Surely almost everyone has made up their minds about whether they support Donald Trump or Joe Biden? While the sliver of voters who are still undecided about the presidential elections is small, there’s more to the US election than just the presidency. This year, 35 seats in the US Senate and all 435 seats in the US House are up for election. In addition, state legislatures, state ballot initiatives, and a host of other races (including school board members and county drain commissioners in some states) are up for elections.

Coverage of state-level elections is spotty on Wikipedia. The coverage of some states in some years is excellent, but most lack even the most basic set of information about the election. Like everything else, the articles that get written are those catch the interest of Wikipedia’s volunteer editor base. In August, to try to get better information relevant to voters in the 2020 elections, we ran our Informing Citizens Wiki Scholars class.

Several participants in the course focused on state-level election pages. New articles were created about the 2020 Tennessee Elections and 2020 Kansas Elections, while a new article about the 2020 Colorado Elections was created jointly by a class participant and another Wikipedian (in the serendipitous way that collaborations sometimes work on Wikipedia). Other people focused on specific issues, like improving the Oakland Unified School District or the 2020 California Proposition 14 article. Given the relevance of climate change to voters decisions, another participant decided to improve the volcanic gas article to make it clear that the amount of carbon dioxide emitted by volcanoes is small compared to anthropogenic emissions.

Courses like these are important ways to encourage subject matter experts to contribute their research skills and knowledge to Wikipedia, ahead of when these pages will be most important as voters seek neutral, fact-based information. To see a current list of course offerings, visit learn.wikiedu.org.

This fall, we’re celebrating the 10th anniversary of the Wikipedia Student Program with a series of blog posts telling the story of the program in the United States and Canada.

I was reflecting on how Wikipedia’s gender gap has changed over the past 10 years when I heard the news that Supreme Court Justice Ruth Bader Ginsburg had passed away. It was sort of apropos, as I think Justice Ginsburg’s fight against discrimination on the basis of sex resonates with those of us who have spent 10 or even 20 years (almost!) fighting for better gender representation on Wikipedia.

Like the broader fight for gender equity in the United States, it can feel especially degrading to read constantly about the poor state of gender parity on Wikipedia, especially when you know so many people working hard to bring women’s voices and knowledge to the masses through the encyclopedia. Over the last few years, journalists have written about Wikipedia’s egregious gender gap in the New York Times, The Atlantic, Ms. Magazine, the Washington Post, and so many other media outlets. The story is usually the same: English Wikipedia’s volunteer editors largely (at least 85%!) identify as men; women experience bad harassment when they try to participate; where are all the women?! And occasionally, you get an inspirational anecdote about one person or group working to upend the gender imbalance on Wikipedia.

None of this is inaccurate. As far as we know, our community hasn’t made major progress in attracting more regular editors who identify as women over the last 10 years, at least not in a way that begins to ensure women’s history is even close to being “complete.” With the barrage of reporting on Wikipedia’s gender gap, it’s easy to think we’ve made no progress over the last 10 years. But for those of us in the community, who constantly critically evaluate Wikipedia content, processes, and editors, we know there have been some inspirational leaps forward to make this website more representative of human knowledge. And like Notorious RBG’s many victories for human rights, we have so many successes to celebrate, and I don’t think we talk about them enough. Now that we have run our flagship program for 10 years, I’d like to highlight some major successes, both from within the general Wikipedia community and from Wiki Education’s program participants.

First: What is the Wikipedia gender gap?

According to various studies, only 9–16% of Wikipedia’s editors identify as women. In 2011, the Wikimedia Foundation—the non-profit that powers Wikipedia—set a lofty goal for its 5-year strategy: increase participation on Wikipedia to 25% women. Spoiler alert: we’re still not there, nearly a decade later. But our community has embraced that the gender gap is, in fact, a problem, and several people, groups, and organizations have taken the initiative to build a more inclusive encyclopedia.

Student editors help close the gender gap

One of the most powerful aspects of our Student Program, which we’ve been running for 10 years, is that Wikipedia assignments bring new editors who may never have contributed content on their own. In the spring 2020 term, roughly 60% of our students identified as women. Of the 7,500 students we supported, that means approximately 4,500 women came to Wikipedia over a four-month span thanks to their instructors’ choice to incorporate a Wikipedia assignment into their curriculum. While they may not have come of their own volition, they quickly learned how much they have to offer thanks to their studies, their lived experiences, and their access to academic publications through the university library.

And of course what makes this so important is not just that they participated in building Wikipedia but what knowledge they shared with millions of readers. Take Dr. Nadine Changfoot’s fall 2019 student at Trent University in Ontario, who expanded the article about reproductive justice. This student added a section about coerced sterilizations of Indigenous women in Canada, which happened as recently as 2018 but was not previously covered on a page that skews heavily toward the United States. Approximately 2,000 readers access that article each month, and thanks to this student, they now have a more global understanding of reproductive justice and injustice.

Another student in Dr. Jo Ann Griffin’s fall 2019 course at the University of Louisville worked on the article about transgender health care. Specifically, they added a section about mental health, citing studies reporting high suicide rates in the transgender community. Perhaps more importantly, they cited reports that mental health struggles decrease when transgender individuals transition—either socially and/or medically—to their identified gender. This information about mental health problems (and potential solutions!) was previously missing from a page that reaches 1,500 readers per month. Some of those readers are likely transgender themselves, and I’m incredibly proud that one of our students had the opportunity to summarize and share this scientific literature with the world thanks to their university assignment.

Our community is better thanks to community organizing

If you are new to Wikipedia, you may not know that we consider ourselves a community. I’ve spoken with thousands of people over the years about Wikipedia, and I feel like I’ve heard it all: Where does content come from?; So who approves changes?; Are Wikipedia pages imported from other encyclopedias? But our incredible community of volunteers makes the entire project possible, including more than 6 million articles on English Wikipedia alone. So how does a relatively small percentage of the population keep it up? Largely through community organizing—either on-wiki or offline.

Over the last 10 years, we’ve seen a ton of community groups form to help curb Wikipedia’s gender gap. In July 2015, a small group of Wikipedians founded Women in Red after assessing Wikipedia’s biographies (anyone from scientists to musicians to cricket players) and realizing only 15.53% of the total biographies were of women. This group has grown to hundreds of active members who work each day to recognize women and their achievements. We’ve seen the percentage of women’s biographies increase to 18.58%, and, as I like to joke, that’s without mass deleting biographies of men. This dedicated group of volunteers builds lists of missing women, creates new biographies, runs virtual and in-person events, lends a helping hand to new editors like our students, and presents at Wikipedia conferences to raise awareness about their project and the need to add more women into the encyclopedia.

A like-minded group, Art + Feminism, launched a campaign in 2014 to add women artists to Wikipedia during community-led edit-a-thons (events where experienced Wikipedians guide newbies through their first contributions). Their initiative has expanded into a non-profit organization that works to counter the gender gap in the arts on Wikipedia, and their participants have improved more than 84,000 biographies on various language Wikipedias, Wikidata, and other ally projects.

Another group that emerged in 2015, AfroCROWD, regularly hosts edit-a-thons in partnership with GLAM institutions to add Black culture and history to Wikipedia. I’d be remiss to ignore how intersectional feminism is and that, for example, in order to support women on Wikipedia, one must support Black women on Wikipedia. The editors at AfroCROWD have done phenomenal work over the past 5 years not only to raise awareness about content gaps on Wikipedia, but to facilitate as experienced and new editors work to close those content gaps.

These are just a few of the groups working hard to make Wikipedia more representative of the sum of all human knowledge, and it’s one of the most impactful changes we’ve seen to the gender gap over the past decade. Wikipedia is only as good as its community members, and its community only becomes more inclusive as it reaches out a purposeful hand to guide new editors excited to lend their voice to our projects.

Strategic partnerships and targeted content

One of the approaches to diversifying Wikipedia that we’ve taken at Wiki Education is to form strategic partnerships. In 2014, we partnered with the National Women’s Studies Association (NWSA) to launch a Wikipedia initiative for their members, who teach in Women and Gender Studies (WGS) departments in colleges and universities. At this time, NWSA actively asked their members to use Wikipedia as a teaching tool, and they regularly gave Wiki Education a platform to share why this experience is so meaningful to students. We have since supported more than 400 WGS courses with nearly 9,000 students in our Student Program. They’ve added a staggering 6 million words to Wikipedia, or more than 4 volumes of the last print edition of Encyclopedia Britannica. Students in these courses have shared knowledge with the world about so many topics related to gender and intersectional feminism: from disability studies, to LGBT rights in Nepal, to Black feminism, to countless biographies of notable women.

And for Wiki Education, as so much has changed over the last decade, one of the most significant is the way we partner with mission-aligned institutions. Now, with our Scholars & Scientists program, we’re able to partner with institutions who are eager to improve a specific topic area and directly train their members, faculty, or other stakeholders how to lend their expertise to relevant topics. Thanks to this program, we’ve partnered with the Society of Family Planning to train more than 40 medical practitioners and scholars how to fill in content gaps on Wikipedia related to women’s health. This work has given the public better access to information about women’s health in Uganda, telehealth and medical abortion access during a pandemic, and tubal ligation and other common medical procedures.

Through our collaboration with the National Archives and Records Administration (NARA), we facilitated as historians and archivists rewrote the Wikipedia article about the 19th Amendment. Before these scholars got to work as a part of our course, the article documenting the Nineteenth Amendment, which prohibited governments from discriminating against voters on the basis of sex, not only centered the narrative on white people, but on white men. The Wiki Scholars added crucial information about how this amendment did not enfranchise women of color. We’re so grateful for the opportunity to work with subject-matter experts who are eager to join the Wikipedia community but are not ready to do so on their own.

The next 10 years

2030 has been a hot topic in the Wikipedia community for the last several years, as our global community has worked together to envision what our projects might look like in 2030. I’m certain we’ll have made progress in ways I can’t even imagine at this stage. What I can imagine is that we’ll finally make changes within the community that will invite more women, non-binary people, and other currently underrepresented groups to participate, both in knowledge production and as subjects of Wikipedia articles. I envision an encyclopedia more inclusive of oral histories and less restrictive of notability. One that treasures educators as much as military leaders. I’m certain university students will still be finding and fixing missing, inaccurate, or misrepresented information, and our community will still work best when organizing to make Wikipedia and the world a better place. I’m hopeful we’ll create systems outside of Wikipedia that better support women, creating more “free time” to build an encyclopedia. When I’m asked when there will be enough women on Wikipedia, and my answer is “when there are 90% women editors,” people are shocked. But there’d been 90% men, and it took a decade for anyone to ever raise a question about that.* **

* Adapted from Ruth Bader Ginsburg’s famous quote about the gender imbalance of the Supreme Court.
** This is a joke.

By Emanuele Rocca, Staff Site Reliability Engineer, The Wikimedia Foundation

The Wikimedia Foundation, the non-profit organization behind Wikipedia and other well known wiki-based projects, operates websites and services that are high volume and rank in the world’s top 20. We serve about 21 Billion read requests per month and sustain 55 Million edits to our articles. On a normal day over 90% of these read requests are served by our caching solution, our own Content Delivery Network (CDN). Like other parts of our technology stack, the CDN is based on Open Source software and is constantly evolving. During the last couple of years, we have performed various changes in terms of on-disk HTTP caching and request routing.

This 3 part series of articles will describe some of the changes, which included replacing Varnish with Apache Traffic Server (ATS) as the on-disk HTTP cache component of the CDN. ATS allowed us to significantly simplify the CDN architecture, increase our uptime, and accelerate the procedure to switch between our two primary data centers in Virginia and Texas.

Wikimedia serves its content from 2 main data centers (DC) and 3 caching-only points of presence (PoP). The two main data centers run all stateful services such as databases, job queues, application servers, and the like, as well as load balancers and HTTP caches. Instead, PoPs only run HTTP caches and the load balancers required to route traffic among them. The two main DCs are located in the United States, specifically in Virginia (short DC name: eqiad) and Texas (short DC name: codfw). The eqiad data center is the one normally serving cache misses, while codfw is a hot standby. Caching-only PoPs are available in Amsterdam (esams), Singapore (eqsin), and California (ulsfo).

Our work is done in the open, and dashboards are no exception. See, for instance, the traffic patterns of Wikimedia DCs shown above. The CDN serves up to 150K requests per second.

Back to 2018: Varnish and IPSec

The diagram depicts the CDN architecture up to 2018. We omitted the Singapore PoP for clarity, but it works fundamentally as the California PoP.

Users are routed via GeoDNS to the PoP geographically closest to them. Their request results in a cache lookup, and in case of a cache hit the HTTP response is sent from the PoP straight back to the user, with no further processing required. In case of cache miss, instead, the request is sent further through the CDN to the next caching PoP as shown by the arrows. In case of cache misses all the way down, the request ultimately makes its way to the main primary DC.

The response goes back through the CDN (getting stored in the caches it traverses if allowed by Cache-Control and similar response headers) and finally reaches the user. To preserve the privacy of our users, HTTP requests between PoPs need to be sent encrypted. We chose to use IPSec to encrypt traffic due to the lack of outgoing HTTPS support in Varnish.  Green arrows show the standard request flow through the CDN, while white paths represent IPSec connections in stand-by, to be used in case a given PoP needs to be taken down for operational reasons.

Looking more closely at what happens inside a PoP, we can see that each cache node runs three different HTTP servers: one instance of NGINX for TLS termination, one in-memory instance of Varnish for caching in RAM, and one instance of Varnish for on-disk caching. NGINX is necessary to serve HTTPS traffic given that Varnish does not support incoming HTTPS either, but can otherwise be ignored for the purposes of this article.

Requests are served following this simplified 4 steps model:

1. Frontend cache selection
2. Local backend cache selection
3. Remote backend cache selection
4. Request to the origin

(1) The load balancer picks a cache node by applying consistent hashing to the client IP. In case of a cache hit on the in-memory Varnish, the HTTP response is sent back directly to the user. As an optimization, the response goes back to the user without going through the load balancer. This technique is known as Direct Routing and is particularly useful for HTTP traffic, which features comparatively small requests and large responses. Cache misses are further processed by the CDN.

(2) The in-memory Varnish applies consistent hashing on the request URL to pick another cache node within the PoP (local backend) and sends the HTTP request to the on-disk Varnish instance of the node so chosen. In case of a further cache miss, request processing continues at the on-disk Varnish level in another pop (remote backend).

(3) The request is sent to another on-disk Varnish running in the next PoP. In the example above, the request goes from esams (EU, Netherlands) to eqiad (US, Virginia). The request is sent over an IPSec tunnel. In case of yet another cache miss on the remote, on-disk Varnish, the request is sent to the next remote PoP (if any), or it reaches the origin server.

(4) The origin server processes the request, and in our example, the HTTP response goes back via the remote on-disk Varnish in Virginia, the local on-disk Varnish in Amsterdam, the in-memory Varnish in Amsterdam, and finally reaches the user. If cacheable, the response is stored on the various caches it traverses, so that any later request for this object can be served from the caches instead.

Issues and the road ahead

The architecture described so far served us well for a while, though we did encounter various problems and identify areas for improvement. 

Generally speaking, the hit rates on remote on-disk Varnish instances have always been very low (around 1%). Step (3) as detailed earlier in this post was there simply as a workaround for lack of TLS support in Varnish and could be avoided using an HTTPS-capable caching proxy instead.

Furthermore, the on-disk cache instances were affected by serious scalability and reliability issues. Varnish supports various types of storage backends for its cache contents. Up to version 3, the persistent storage backend was our backend of choice and worked very well in our usage scenario: it worked reliably and allowed us to store cache objects on disk. Further, the cache was persistent, in the sense that we could restart Varnish without losing the cache.

The persistent storage backend was deprecated in Varnish version 4, and replaced in the proprietary version of Varnish by a storage backend with similar features and called Massive Storage Engine.   FOSS users were thus left with the option of using the file storage backend, which had two major drawbacks: (1) no support for persistence (2) scalability issues.

The second problem, in particular, was occurring after a few days of production use: a sizable number of requests would result in 503 errors, and normal operation could be resumed only by restarting Varnish. As a bandaid, we introduced a cron-job restarting Varnish on a weekly basis. Unfortunately, this frequency of restarts did not prove to be sufficient, and we had to resort to restarting Varnish twice a week to reduce the frequency of user-facing outages. The issue turned out to be a known architectural limitation of the file storage engine. After several debugging sessions we concluded that it was time to start looking for alternatives.

As a viable replacement for Varnish we identified Apache Traffic Server: an Apache Software Foundation project used and developed by many large organizations including Apple, Verizon, Linkedin, and Comcast. A migration to ATS would solve our two major pain points with Varnish: it supports persistent storage on-disk reliably, as well as incoming and outgoing HTTPS. 

In the next post, we will describe the architectural changes made possible by migrating the on-disk component of our CDN to Apache Traffic Server.

About this post

Featured image credit: North America from low orbiting satellite Suomi NPP, NASA/NOAA/GSFC/Suomi NPP/VIIRS/Norman Kuring, Public Domain