{{Hatnote}}

Unlocking the human potential of Wikidata

Wikidata is amazing. Thanks to the amazing Wikidata evangelists out there, I feel confident that, given at least five minutes, I can convince anyone that Wikidata offers a critical service necessary for Wikipedia, other wiki projects, and generally the future of knowledge. Challengers welcome. :)

But Wikidata has a problem. Right now it’s optimized to ingest and grow. We’ve written about how it’s not ideal for maintenance of the datasets, but automated ingestion of datasets is what Wikidata does best.

All this automated growth doesn’t necessarily connect well with the organic growth of Wikipedia and other projects. And we can see that Wikidata hasn’t truly captured the positive attentions of existing editor communities.

For that human touch Wikidata needs ever so much, it must reach out to the projects that gave rise to it.

One idea for doing this would be to make human editing of Wikidata easier. Make editing Wikidata as easy as adding a citation to Wikipedia. Literally.

Highlight a statement, click a button like “Structure this statement” and grow Wikidata, all without leaving your home wiki.

What it might look like to edit Wikidata from Wikipedia.

While Wikitext will always have its place for me, I’ve quite warmed up to the visual editor, and prefer its interface for adding citations. While it’s only an idea for an experiment at the moment, how might an inline Wikidata editor following the same pattern could be change the game for Wikidata?

A lot of data is already citing back to home wikis, but a powerful enough editor could pull the citation on a statement through to the Wikidata entry, along with the import source.

So much data is already coming from Wikipedia, but humans can do even better.

I have always thought it would be great to see Wikidata’s support for multi-valued properties leveraged more fully. A language-agnostic knowledgebase will be a new space to compare and resolve facts. A meeting of the many minds across different languages of Wikipedia could spell better information for all.

An advanced enough system could encourage contributions on the basis of coverage, highlighting cited statements which have not yet been structured.

And of course, at the very least, we speed up building an intermediary representation of knowledge, not tied to a specific language. People sharing knowledge across wikis, helping to further bootstrap a Wikidata community with close ties to its older siblings.

Wikicite 2017, and the 7 features Wikidata needs most

At Wikicite 2017, discussions revolved around an ambitious goal to use Wikidata to create a central citation database for all the references on Wikipedia. Citations are the essential building blocks of verifiability, a core tenet of Wikipedia. This project aims to give citations the first-class treatment they deserve.

We saw three important questions emerge at the conference:

• What does a good citation database look like?
• How can we build this on Wikidata?
• How can we integrate this with Wikipedia?

These are hard questions. To answer them, Wikicite brought together:

• Expert ontologists and librarians specializing in citation and reference modeling
• Groups like Crossref with treasure troves of rich bibliographic data.
• Developers and data scientists with experience importing datasets into Wikidata.

Wikicite may be young, but clear progress has been made already. Wikidata now boasts some great collections of bibliographic data, like the Zika corpus and data from the genewiki project. Some Wikipedias, like French and Russian, are experimenting with generating citations using Wikidata. Some citation databases are integrated with Visual Editor to make it easy to add rich citations on Wikipedia–which can hopefully one day be added to Wikidata for further reuse and tracking.

There are still a few features that Wikidata needs to be a first-class host for citation data. Even the best structured data takes time to define in Wikidata’s precise terms of items, properties, modifiers, and qualifications. Although it’s possible to use some handy tools on Wikidata for bulk actions, it often requires changing your dataset to match the tool’s specific format, or writing bespoke code for your dataset. It’s still challenging to ensure data is high quality, well-sourced, and ready for long-term maintenance.

In listening to researchers’ talks, discussing with experts in working groups, and workshopping code with some of Wikidata’s soon-to-be biggest users, we determined that Wikidata needs seven features for true Wikicite readiness:

1. Bulk data import. There must be an easy process for loading large amounts of data onto Wikidata. There are a few partial tools, like QuickStatements, which, while itself aptly-named, is just one part of an often-arduous workflow. Other people have written custom bots to import their specific dataset, on top of libraries like Wikidata Integrator or pywikibot. Without help from an experienced Wikidata contributor, there is not an easy self-service way to move data in bulk.
   
   
2. Sets. Wikidata needs a feature to track and curate specific groups of items. Sets are a necessary concept to answer questions about a complete group. Right now, you can use Wikidata to tell you facts about the states in Austria, but it cannot tell you the complete list of all states in Austria. Sets are key for curators to perform this sort of cross-sectional data management.
   
   
3. Data management tools. Data curators need tools to monitor data of interest. Wikidata is big. The basic tools like watchlists were designed for Wikipedians articles on a much smaller scale, with a much coarser granularity than the Wikidata statement or qualifier. An institution that donates data to Wikidata may want to monitor thousands (maybe hundreds of thousands) of items and properties. Donors of complete datasets will want to watch their data for deletions, additions, and edits.
   
   
4. Grouping edit events. At the moment, many community members are adding data to Wikidata in bulk, but this is a fact that Wikidata’s user interface struggle to represent. Wikidata currently offers a piecemeal history of user’s individual edits, and encourages editors to add citations and references for individual statements. These features are vital, but we need a higher-level grouping feature for higher-level data uploads. For instance, it would be helpful to have an “upload ID” for associated edits across many claims. It would also be useful to have a dedicated namespace for human- and machine-readable documentation of the data load process, a kind of README that addresses the whole action. This kind of documentation not only helps community members get answers to questions before, during, and after large-scale activity, but it also helps future data donors learn about and follow best practices.
   
   
5. A draft or staging space. There should be a way for people to add content to Wikidata without directly modifying “live” data. Currently, when something is added to Wikidata it is immediately mixed in with everything else. It’s daunting for new users to have to get it right on the first try, let alone take quick corrective action in the face of inevitable mistakes. Modeling a dataset in Wikidata’s terms requires using Wikidata’s specific collection of items and properties. You may not see how your data fits into Wikidata—perhaps requiring new properties and items—until you begin to add it. Experienced Wikidata volunteers may review data to ensure it’s high quality, but it would be better to enable this collaborative process before data is part of the project’s official collection. You should be able to upload your data to a staging space on Wikidata, ensure it’s high quality and properly structured, and then publish it when it’s ready. The PrimarySources tool is a community-driven start to this, but such a vital feature needs support from the core. In the longer term, this feature is a small step toward maximizing Wikidata consistency, by setting the stage to transactionally add and modify large-scale data. It would be helpful to have data cleanup tools, similar to OpenRefine, available for data staging.
   
   
6. Data models. Wikidata needs new ways to collaborate on new kinds of items. Specifically, we need a better way to reach consensus on models for certain standard types of data. Currently, it’s possible describe the same entity in multiple ways, and lacking a forum for this process, it’s hard to discuss the differences. See, for instance, the drastically different ways that various subway lines are described as Wikidata items. Additionally, some models may want to impose certain constraints on instances, or at least indicate if an item complies with its model. Looking to the future, tools for collaborative data modeling would grow to include a library of data models unlike any other.
   
   
7. Point in time links. There should be a way to share a dataset from Wikidata at a given point in time. Wikidata, like Wikipedia, is continuously changing. Wikipedia supports linking to a specific revision of an article at a point in time using a permalink, and you can do the same for a specific Wikidata item. However, Wikidata places special emphasis on relationships between items, yet does not extend the permalink feature to these relationships. If you run a query on the Wikidata Query Service (the SPARQL endpoint for Wikidata), and then share the query with someone else, they may see different results.

These seven features came up consistently across several groups and discussions at Wikicite. As a room full of problem solvers, several good projects are already underway to provide community-based solutions in these areas. Among the handful that were started at the conference, we are pleased to share we’ve started work on Handcart, a tool for simplifying medium-sized bulk imports, for citation data, and much, much more. We believe trying to fix a problem is the best way to learn its details and nuances.

Wikicite made a strong case that Wikidata has a lot of valuable potential for citations, and citations are crucial for Wikipedia. As we work to address these missing features in Wikidata, we are happy to be part of the Wikicite movement to build a more verifiable world.

Thanks for inviting us, Wikicite, hope to see everyone again next time!

(Photos are CC-BY and can be found here and here)

Wikicite 2017

Having a great pre-WikiCite gelato social here in Vienna. Also, say hi to the newest Hatnote contributor, Pawel. He does the frontend for Montage and also does great work on Monumental. As you can see, we’re all pretty excited for what Wikicite 2017 will bring (and also ice cream).

Montage and Wiki Loves Monuments 2016

Hatnote welcomed the holidays this year even more than usual, as they coincided with a fine end to another successful chapter of Wikipedia-related work. We’ve got several projects to talk about, but the centerpiece this year is Montage.

Montage is a judging tool used to judge well over a hundred thousand of the submissions to this year’s Wiki Loves Monuments photography competition.

We wrote more about it over on the Wikimedia blog, take a look!

In the meantime, happy holidays from Stephen, Pawel, me, and the rest of the Hatnote crew!

Hopefully next year we’ll all be able to make it into the holiday photo!

Hashtags, One Year In

It’s been around one year since Hatnote announced hashtags on Wikipedia. The Wikimedia Blog has a full story on several of the impacts and inroads being made by supporting this powerful convention on Wikipedia.

Follow that link or if you’re in a hurry, check out the new Wikipedia Social Search interface directly!

Announcing the Hatnote Top 100

Moreso than any other major site, Wikipedia is centered around knowledge, always growing, and brimming with information. It’s important to remember that the insight of our favorite community-run encyclopedia often follows the focus of its massive readership. Here at Hatnote, we’ve often wondered, what great new topics is the community learning about now?

To shed more light on Wikipedia’s reading habits, we’re pleased to announce the newest addition to the Hatnote family: The Hatnote Top 100, available at top.hatnote.com. Because we can’t pass up a good headwear-based pun.

Updated daily, the Top 100 is a chart of the most-visited articles on Wikipedia. Unlike the edit-oriented Listen to Wikipedia and Weeklypedia, Top 100 focuses on the biggest group of Wikipedia users: the readers. Nearly 20 billion times per month, around 500 million people read articles in over 200 languages. Top 100’s daily statistics offer a window into where Wikipedia readers are focusing their attention. It also makes for a great way to discover great chapters of Wikipedia one wouldn’t normally read or edit.

Clear rankings, day-to-day differences, social media integration, permalinks, and other familiar simple-but-critical features were designed to make popular Wikipedia articles as relatable as albums on a pop music chart. In practice, popular news stories and celebrities definitely make the Top 100, but it is satisfying to see interesting corners of history and other educational topic sharing, if not dominating, the spotlight.

In addition to a clear and readable report, Top 100 is also a machine-readable archive, with reports dating back to November 2015, including JSON versions of the metrics, as well as RSS feeds for all supported languages and projects. It’s all available in over a dozen languages (and we take requests for more). The data comes from a variety of sources, most direct from Wikimedia, including a new pageview statistics API endpoint that we’ve been proud to pilot and continue to use. And yes, as with all our projects the code is open-source, too.

For those of you looking to dig deeper than Wikipedia chart toppers, there are several other activity-based projects worth mentioning:

• stats.grok.se - The original, venerable pageview grapher and API
• Wikimedia Report Card - Advanced metrics and data used by the Wikimedia Foundation
• The Open Wikipedia Ranking - Traffic stats and more
• @WikipediaTrends - A bot posting notable upward traffic spikes
• The Top 25 Report - A manually-compiled weekly report of views and likely reasons
• The Weeklypedia - Weekly edit statistics, emailed and archived by Hatnote

And there are other visualizations on seealso.org as well. But for those who like to keep it simple, hit up the Hatnote Top 100, subscribe to a feed, and/or follow us on Twitter. See you there!

P.S. The Wikimedia Blog featured us in the actual announcement for the PageViews API. Yay!

De Venezuela a Gran Hermano: los artículos más editados de Wikipedia en español

De Venezuela a Gran Hermano: los artículos más editados de Wikipedia en español. Noticias de Tecnología. 142 de los 500 artículos más revisados de Wikipedia en lengua española están relacionados con el fútbol. La geografía es la siguiente gran categoría en número de edición de artículos. ...

We recently helped El Confidencial get statistics about the most edited articles on Spanish Wikipedia. You can see a few clusters of popular topics, such as countries, sports teams, and TV shows. You can also compare the data with the most edited topics on English Wikipedia.

If you want weekly updates on the most edited Wikipedia articles, don’t forget to sign up for Weeklypedia!

Hatnote Recent Changes

Almost two weeks since launching IFTTT and it’s still keeping our hands full. There have been over 11 million Recipe requests handled. And Wikipedia’s public Recipes are popular enough to have already made it the #89 IFTTT Top Chef, too.

Even with all the success, Hatnote’s already back in the workshop cooking up new changes. We’ve talked to a few, but we’re definitely taking further user feedback from any thousands of Wikipedia+IFTTT who’d like to chime in on our Ask.

Other changes:

• Brand new Tumblr theme from scratch. Still minimalist, but much more responsive and technically compliant.
• New Social Search frontend and backend yielding 100x faster hashtag searches. Here’s one hashtag search from a recent #TechLadies editathon.
  
• Weeklypedia’s data is now automatically backed up daily on Github. There are probably a few neat visualization projects one could do with over a year of a week-long sliding window of edit data from everyone’s favorite encyclopedia.

And we’ve got plenty more updates in store, see you in another couple weeks!

Build Your Own Topic Bot

It’s been 10 days since the new Wikipedia IFTTT channel launch, and the response has been amazing. Our backend has seen almost 2.5 million requests for Recipe updates, from tens of thousands of unique users. In this post we wanted to do a quick hands-on guide showing one way IFTTT helps Wikipedians reach a wider web.

From drones to Florida news to aesthetic blogs to fake news to drones, topic-specific streams are drawing a big audience these days. Running one isn’t as easy as it looks, though. Content doesn’t create and curate itself. Unless you automate. Case in point, here at Hatnote, the fleet of special-interest Twitter bots built on Wikipedia and IFTTT just keeps getting longer. Here’s a selection from the last week:

• @WikiRedlist: Track the status of critically endangered species.
• @Wikidemics: Find out when doctors (PhDs, JDs, MDs, etc.) join Wikipedia.
• @NotableDeath: Reports recent passings of people with Wikipedia pages.
• @GreeceEdits: Updates on pages related to the Greece crisis.
• @SveWikipedia: Tweets about opportunities to collaboratively edit Wikipedia.
• @FlagsForDays: Updates on flag design and vexillology.

And you can have your very own with 5 simple steps. It only takes about 10 minutes, so let’s get started!

Step 1: Pick a topic

Before signing up for anything, first let’s sort out our goals. If you’re running an editathon or are an experienced editor, maybe you already have a topic or tracked hashtag in mind. For the rest of us, English Wikipedia alone has millions of articles and hundreds of thousands of categories. Think about your audience, but above all, pick something you’re interested in. If you’d like to pick something out of a hat, try a random article or try watching Listen to Wikipedia and seeing if anything catches your eye. Wikipedia excels as a source of random history and science, but also current events.

Here are some more fun entry points for browsing Wikipedia:

• List of lists of lists
• High-level categories
• Contents
• Recent changes
• Portals
  • Current Events Portal
  • All Portals

Step 2: Register your Twitter username

This is the hardest part. Finding and picking a name that is available. Twitter has a billion registered users. It might take you a minute or two to come up with a username that doesn’t have two tweets from 2011.

You’ll need to create a new Twitter account. Here’s a timesaver: Gmail (and other email providers) treat emails such as janedoe+anything@gmail.com the same as janedoe@gmail.com. So you can skip creating a new email and just use your existing one, such as youremail+yournewtwittername@gmail.com.

Step 3: Register for IFTTT

Even if you already have an IFTTT account, registering a new one makes the process go smoother and keeps your Recipes more organized in the long run. You wouldn’t want your bot’s recipes mixed up with your personal ones. You can use the same email trick from Step 2 on IFTTT.

Step 4: Connect the IFTTT Channels

Go to the Wikipedia IFTTT Channel and click Connect Channel. You should see a success message in a moment.

Go to the Twitter IFTTT Channel and click Connect Channel. Then, log in as the special-purpose account we just created to authorize IFTTT to post on its behalf. When you see the success message, you’re done!

There are many other channels worth exploring as outputs for your Wikipedia criteria. More on that later.

Step 5: Create the Recipes

Finally we get to the fun part. Choosing and creating the recipes. Here’s where you get creative, but there are three Triggers worth highlighting:

• Hashtag (docs) - Fires on edits with a #hashtag in the comment. Particularly useful if running an Editathon.
• Added to category (docs) - Triggers when an editor adds an article to a Category.
• Modified in category (docs) - Fires whenever an article in a Category is edited.

Depending on how articles have been categorized, to really cover a subject you may have to create more than one Recipe. Still, this is Wikipedia. If you see something that can be improved, don’t hesitate to try out creating or adding to a Category!

And that’s it! Your bot is operational. No backend work necessary, just some old-fashioned research on a new-fashioned encyclopedia. Here are some parting tips:

• Consider sprinkling in human commentary for a more engaging reader experience.
• Keep an eye on posting rate to make sure it’s not too fast-paced for your service or audience.
• If there’s not enough posts, add more Recipes!
• If you have an international audience, you may want to use interlanguage links, found at the bottom of the sidebar on the left of Wikipedia pages, to connect Categories from different languages’ Wikipedias.
• If you want to post to other channels, you can have a single recipe watch the Twitter feed and copy it over to Tumblr, Facebook, or other platform of choice.
• Twitter recommends you get and maintain real followers as soon as possible to ensure that your bot performs well in search rankings.

As always, as soon as you create your bot, tweet at us so we can add it to the list!

Wikipedia and IFTTT: A Technical Guide

Here at Hatnote we build on Wikipedia a lot. And while we love building projects like Listen to Wikipedia and The Weeklypedia, we have to admit programming, integrating, and maintaining reliable services can be a lot of work. Creating cool and functional Wikipedia projects remains out of reach of most busy Internet denizens. Until today.

With the aim of bringing Wikipedia to the wider web, Stephen and I are pleased to have worked with Wikimedia and IFTTT to build the brand-new Wikipedia IFTTT channel. This post is your 10-minute usage and technical guide to all things Wikipedia+IFTTT. For the official announcement, see the Wikimedia blog.

IFTTT connects web services, so when something happens on one service (the Trigger), it pushes an update to another service (the Action). With the new Wikipedia channel, so you can create customized combinations, called Recipes, to plug Wikipedia into your Internet ecosystem. With this new channel, Wikipedia offers eight new Triggers that can be connected to IFTTT’s 200+ other channels, including email, phone, Android, iOS, Twitter, Tumblr, Slack, and many more. There are already dozens of example Wikipedia Recipes ready for activation.

Even if you’re already familiar with IFTTT, a few things set Wikipedia apart from other channels. Foremost, whereas most other services provide an API to data and information, Wikipedia provides a direct interface to curated knowledge. So trust us when we say it pays to invest in learning the special nature of Wikipedia, as seen through the lens of the new IFTTT Triggers.

The Daily Triggers

• Article of the Day
• Picture of the Day
• Word of the Day

The simplest of the new Triggers, these three update once per day around midnight UTC. Their simplicity makes them the perfect candidates to introduce Wikipedia Fact #1:

> Fact #1: There are many Wikipedias! Most people are familiar with Wikipedia as one site. But unlike other IFTTT channel providers, the fact is there is one Wikipedia per language, each with its own conventions and quirks. We’ve made all the new Triggers customizable for all Wikipedia’s 290 languages. So keep in mind for future triggers, a recipe that works well on one language, may not apply at all to the others. As a multilingual Wikipedia editor, I’ve found clicking the interlanguage links on individual articles and referring to the Weeklypedia archives are good ways to get acquainted with the differences.

The Daily Triggers are are an exception to the interlanguage differences. Almost all Wikipedias, regardless of size and age, follow the convention of featured articles. So feel free to get a weekly dose of free knowledge in your language of choice!

Edits to an Article

When most people talk about Wikipedia, they’re talking about the articles, Wikipedia’s fundamental unit of knowledge organization. Articles are written by many users contributing what knowledge they can, edit by edit.

On the surface, the Edits to an Article Trigger is simple. If you have a favorite article, IFTTT will monitor it for changes and notify you when an edit occurs. But of course there are caveats.

> Fact #2: Wikipedia is a uniquely open platform. That openness is reflected in the data passing through IFTTT APIs. Don’t be surprised to see raw or non-constructive changes made (and usually reverted) by Wikipedia editors, often in quick succession.

> Fact #3: Wikipedia is a community with many subcommunities. Quality, approaches, and discipline will vary between these subcommunities. For instance, to match naming conventions, it’s common for articles to be renamed (“moved”) multiple times, especially when they’re brand new.

If you’re learning new things from the facts and think you might have some better solutions, Wikipedia wants to hear about them. In the meantime, you can have IFTTT DM you on Twitter when there are updates to the discussion or new terms that might help in the debate.

Edits from a User

Editors write articles. You don’t need to be logged in to edit Wikipedia, but it helps with site customizations and better edit history maintenance. Now, using the Edits from a User Trigger you can easily connect a given user’s edit activity with other social sites, making Wikipedia more personal than ever.

Other than Stephen and me, finding interesting users to follow is a topic for another post. But there is one type of user that has garnered a lot of attention in the past: the Bots. Wikipedia’s Bots are more administrative power tool than autonomous overlord, but people are still obsessed. Just as well, because this brings us to the next fact.

> Fact #4: Wikipedia grows at different speeds. Some pages change quickly, some slowly. Generally the larger the item, the faster it changes, unless it’s brand new. This is even visible at the site level: English Wikipedia sees about 100,000 changes per day, French has 20,000, and Farsi has 200. If your Trigger event is too high-velocity, occurring more than 50 times per hour, it is likely not a good fit for IFTTT, and you could get temporarily blocked by a Recipe’s Action’s service. If it’s too low-velocity, you might be disappointed with an otherwise sound recipe.

Some bots, like ClueBot, are very active, and would not play well with IFTTT. Other bots edit only a couple times a day, like SpaceFactsBot. It updates space-related world records in progress, and would be a fine IFTTT Trigger candidate. Tweet its edits (or your own), by filling in this recipe.

Edits with a Hashtag

Hatnote is a big fan of hashtagging on Wikipedia. Hashtags are the best way to unify edits with a common purpose across articles and editors. If you’re editing with friends, colleagues, or Editathon participants, easy-to-use hashtags build momentum and record your hard work.

> Fact #5: Set up earlier rather than later. This is hardly specific to Wikipedia, but whenever possible, setting up a recipe beforehand is way easier than retrieving the data later. Don’t forget to test them out to make sure they work! That’s what the Sandbox is for.

With a little bit of forethought and the Edits with a Hashtag Trigger, you can automatically build that record into a blog or other manifest. You can even push it to a Google Spreadsheet, and access that as a form of JSON API, giving you a whole API backend in no time.

Article added to a Category

We’ve saved the best for last, because now we’re getting into the most complex and exciting Triggers in this release. The Article added to Category Trigger is one of our favorites because it is so open-ended. You can get really creative with them. Just look at these Recipes:

• Call me if there is a new President of the United States
• Send me an email when a Wikipedia user earns a PhD
• If The Truth Is Out There, I Want To Believe

In case you hadn’t interacted with them before, Categories can be found by scrolling to the bottom of any Wikipedia article. An article’s associated Talk page often references administrative categories, which are interesting in their own right. In fact, due to technical limitations for this recipe and the next, Talk page changes are automatically resolve to their “main” namespace counterparts. Talk goes to the Article namespace, User talk to User, Project talk to Project, etc. It is not possible to monitor a Talk page exclusively.

Categories are full of promise, and we eagerly anticipate the community’s leveraging of this Trigger, but that promise comes with a price.

> Fact #6: Wikipedia Categories can be problematic. First, the caveats of the previous facts apply doubly to Categories. Category systems and conventions vary greatly between communities and languages. Some Categories are huge and change frequently, others are small or even empty, despite having broad-sounding names. Research is necessary.

>Second, Categories often assume an unpredictable tree structure, wherein parent categories do not automatically contain their subcategories’ members. Furthermore, cycles can exist. Finally, due to the way pages are added and removed to Categories, it is possible for a page to appear to be added to a Category multiple times, simply due to editing snafus. Do not actually rely on the Presidential phone call for your think tank’s next strategy summit.

Most of these complexities are manageable through other means. For instance, if one wanted to monitor a Category’s Subcategories, one would simply have to do a bit more mousework, and set up multiple Recipes to perform the same Action, as we’ve done in the examples for this next Trigger.

Edits to Articles in a Category

Some would argue the most complex Trigger, but for those who have been following along so far, you can probably guess exactly what this will and won’t do. Use the Edits to Articles in a Category Trigger to simultaneously monitor multiple articles related to a specific topic.

From Fact #4, we know that if the topic is too broad, the edit speed may outpace IFTTT’s effectiveness. From Fact #2 and #3 we know that Categories mean different things to different communities. From Fact #6 we know that a given Category may not always be what it appears. And finally, from Fact #1 we know that Categories don’t apply across languages, so we recommend disabling the language customization field for published Category-based recipes.

Add in the Talk-page caveat from the previous Trigger and it’s been a long road, but we’re already reaping the returns. For instance, using the Tweet about Wikipedia Updates in a Category Recipe, there are already three special-interest Twitter accounts running solely off Wikipedia with no specific programming overhead whatsoever:

• @LISedits: Tweets about Library Sciences. We’ve heard librarians love Wikipedia.
• @medstubs: Tweets about newly posted medical articles that could use contributions
• @wikibreakfast: Tweets about the most important meal of the day.

When it’s this easy, one might wonder where all the complexity went. Well, if you’re really curious about the technical details, read on.

Behind the Scenes

Hard at work at Hatnote HQ:

The Article Edit Trigger, User Edit Trigger, and Daily Triggers are based on basic queries to the Wikipedia API. The Wikipedia channel includes a daily update on the Wikipedia Article of the Day, Wikimedia Commons Photo of the Day, and the Wiktionary Word of the Day. All three of these feeds are also available as RSS feeds from the API.

The Hashtag Trigger and Category Triggers are all based on SQL queries to the Wikipedia database replicas that are openly available on Tool Labs. The service that does all the API calls, SQL queries, and serves all the IFTTT requests is written in Python.

The very astute might notice that all the Wikipedia IFTTT features are Triggers for reading as opposed to Actions for editing. While Wikipedia supports OAuth, there are existing community conventions and affordances for automated editing that require further consideration and discussion.

Thanks

Many thanks to Ori, Dario, Ed, Niki, Yuvi, Kirsten, and many others for their hard work and feedback during the Wikipedia+IFTTT development.

We hope you found the guide useful. If you build anything, tweet it out and CC us, our handles are linked below. Happy automating!

– Mahmoud and Stephen

New Weeklypedia Languages

Things are heating up in Hatnote land. First up we’ve got Weeklypedia updates, where we’ve added two new languages to our weekly update on editing activity.

So for you Spanish (hola!) and Farsi/Persian (!سلام)speakers, subscribe here:

• Spanish Weeklypedia
• Farsi Weeklypedia
  

We never spam and hate all that, this is just a summary, pure and simple. If it’s in the news, it’s on Wikipedia, and if it’s big news you won’t want to miss, it’s on Weeklypedia. Plus the interesting mix of all the culture and history you’ve come to expect from Wikipedia, too. Here’s an English example issue from last week. 

In case you’re feeling left out, feel free to submit a request to get your language added, and we’ll add it as soon as we can. Here’s a list of the previously supported languages:

• English
• German
• French
• Korean
• Estonian
• Swedish
• Danish
• Italian
• Catalan
• Esperanto (!)

Next up, Chinese and Urdu! BTW, how about that new site design Stephen built?

Not too shabby, eh?

{{Hatnote}}

Anonymous asked: Sounds like you guys have added bots to the mix. But now its a frantic strumming of activity because of so many bots crawling Wikipedia. Could you add in an option to filter out bots? I liked coming to hatnote for a nice, soothing background melody, but now its way too chaotic.

That’s an interesting observation! Bots have actually been supported from day 1, but you’re right, there is a much higher than usual bot activity right now.

For those that aren’t aware, many of Wikipedia’s more tech-savvy users write automated scripts to do a lot of the grunt work of editing and administrating Wikipedia. This could be anything from fixing typos to renaming categories to preventing vandalism. Every now and then there will be a large migration or bot-assisted editing effort, and Listen to Wikipedia will be rather cacophonous during that time.

So, I’ll see what I can do about adding that option this week, sorry for the inconvenience. For a more relaxing experience in the meantime I’d recommend listening to one or more of the other languages, as usually these traffic spikes only affect one language at a time, and only last for a few hours, maybe a day.

If for some reason you want to listen to a real botfest, check out the Wikidata “language”, which, last I checked, is over 95% automated edits!

Thanks for reaching out!

Mahmoud

{{Hatnote}}

Anonymous asked: Hi! Im contacting you on behalf of Wikimedia Finland. Would it be possible to include fiwiki in to the listen to wikipedia? We would like to use it with hashtags in our events! -Teemu Perhiö, WMFI.

Hey Teemu! Thanks for reaching out. We’ve just added Finland to Listen to Wikipedia, so feel free to hashtag away. Also, ping us on Twitter @mhashemi and @sklaporte so we can pass along the good word!

– Mahmoud