# The Post Quora, Inc. Doesn’t Want You to Read: My Short Experiment With Monetization is Over

Quora is addictive. There are a lot of great things about it. Unfortunately, there are also a lot of awful things about it. The awful things cause me to want to stop writing there. Occasionally, something good happens that makes me want to come back. And then something awful happens again.

Quora’s central problem is that the main page feed is based on a buggy algorithm that mostly shows the users random posts and not posts on topics they actually ask for. Pretty much all the other problems derive from that. Many writers have been complaining about this since 2018. Unfortunately, the Quora staff refuses to acknowledge this problem, and keeps saying that the feed is excellent and that it is Quora’s unique advantage that makes it better than its competitors, such as Substack, Medium, or Reddit. The problem described here is related to it, too.

In the summer of 2021, Quora announced the monetization program. It even made me one of the first people to be able to participate in it. I tried it, and decided to stop. Here’s the post that explains why. I published it in Quora’s official Writer’s Feedback space. After several hours, the moderation hid it.

Yes, it criticizes Quora. That’s what happens occasionally when you welcome feedback. I don’t think I violated any written rules, but it was hidden anyway. If for some reason it interests you, read and decide for yourself.

When the monetization was announced, I was cautiously optimistic about it. For a year, since June 2020, it was possible to get paid only for managing Spaces and not for writing answers or even Space posts, so making it possible to get paid for answers was an improvement. It was a matter of fairness; I never planned to actually earn even a penny from it. I know I’m not popular enough for that, and I don’t plan to do anything to become popular. I’m here to ask and answer questions on relatively niche topics.

Nevertheless, just for the fun of it, I monetized a few answers I wrote over the years. Mostly answers that I am not too proud of, such as not-actually-funny jokes that got too many upvotes. My thinking was that despite the thousands of upvotes, it’s unlikely that I’ll actually get paid for it, but at least it will reduce the number of people who read and upvote that nonsense I wrote once. I could, of course, delete or mute these answers, but monetizing looked like a funnier solution. Maybe I should stop trying to be funny.

Anyway, a few days ago Quora+ was fully launched and I started seeing paywalled answers in the feed. The paywalled answers are just like almost everything else on my feed: written by people that I don’t follow, about topics that I don’t follow, and generally looking like something that I wouldn’t want to read even for free, let alone pay for. I’m not saying that these answers are bad, or that their writers don’t deserve payment. They just don’t interest me. So I muted most of these writers.

I have to reiterate: the problem is not the money. The problem is relevance. I pay for New York Times, Spotify, and some other podcasts and blogs, and I can afford paying 50 U.S. dollars more per year. I just have no reason to pay to read things that don’t interest me.

And I’m hearing from a lot of Quorans here and there, in answers, posts, and comments that they are muting all the writers of paywalled answers that they see on their feed. So it’s not just me.

Since this looks like a certain way to get muted by a lot of users, why would I want to monetize anything? So I went back and removed the monetization from the few answers where I enabled it.

Again, I’m not saying monetization can’t work in principle. It possibly can. But I’m not convinced that this “adaptive paywall” thingie does anything useful, and it makes me think that I’m much more likely to get muted than to get paid.

Here’s an idea: Want to get me to pay for subscription and to think that monetization is worth the risk of losing some readers? Try showing me more paywalled answers from topics and writers I follow in the feed. I literally told you I’m interested in them by following them. If I see that, I may consider monetizing again.

# Linguistic Purism and Software Localization

People who translate MediaWiki and other pieces of software with which I am involved to languages of India, Philippines, African countries, and other places, often ask me: Should we translate to pure native neologisms, or reuse English words?

Linguistic purism is quite common in translation in general, and not only in software. I heard of a study that compared a corpus of texts written originally in Hebrew with a corpus of translated texts. The translated texts had considerably fewer loanwords. This may be surprising at first: how can translated texts have fewer loanwords?

But actually this makes sense: A translator is not creating a story, but re-telling a story that already exists. A good translator is supposed to understand the original story well first, and after understanding it, the translator is supposed to retell it in the target language. Many translators use the time that they don’t invest in creating the story itself to make the translation “purer” than the target language actually is.

A text that is originally written in Hebrew expresses how Hebrew-speaking people actually talk. Despite a history of creating many neologisms, some of which were successful, Hebrew speakers also use a lot of loanwords from English, Arabic, German, Russian, French, and other languages.

And that’s totally OK. Loanwords don’t “degrade” or “kill” a language, as some people say. Certainly not by themselves. English has many, many words from French, Latin, Norwegian, Greek, and other languages, and they didn’t kill it. Quite the contrary: English is one of the most successful languages in the world.

A good original writer creates verisimilitude, naturally or intentionally, by using actual living language. And actual living language has loan words. More in some languages, fewer in others, but it happens everywhere.

Software localization is a bit different from books, however. Books, both fiction and non-fiction, are art. At least to some degree, the language itself is an expressive tool there.

Software user interfaces are less about art and more about function. A piece of software is supposed to be usable and functional, and as easy and obvious to learn and use as possible. The less people need to learn it, the closer it is to perfection. And localized software is no different: it must, above all, be functional.

Everything else is secondary to usability. If the translation is beautiful, but the software can’t be used, the job is not done.

And this is the thing that is supposed to guide you when choosing whether to translate a term as a native word, possibly a neologism, or to transliterate a foreign term and make it a loanword: Will the user understand it and be able to use the software?

The choice is not as obvious as some people may think, however. Some people may think that loaning a word makes more sense because it’s already familiar, and this will make the software familiar.

But always ask yourself: Familiar to whom?

The translator, pretty much by definition, is supposed to know the source language, and to be able to use the software in the source language. Most often the source language is English. So most likely the translator is familiar with the source terminology.

But will the user be familiar with it?

The translated piece of software is supposed to be usable by people who aren’t familiar with that software in the source language, and, very importantly, by people who don’t know the source language at all.

So if you translate words like “log in”, “account”, “file”, “proxy”, “feed”, and so on, by simply transliterating them into the target language because they are “familiar” in this form, ask yourself: are they also familiar to people who don’t know English and who aren’t experienced with using computers?

Some Hebrew software localizers translate “proxy” as something like “intermediary server” (שרת מתווך), and some just write “proxy” in transliteration (פרוקסי). The rationale for “proxy” is usually this: “everyone knows what ‘proxy’ is, and no one knows what an intermediary server is”.

But is it really everyone? Or maybe it’s just you and your software developer friends?

To people who aren’t software developers, the function of “proxy” is pretty much as obscure as the function of “intermediary server”… or is it? Because the fully translated native term actually says something about what this thing does in familiar words.

Of course, if you are really sure that a foreign term is widely familiar to all people, then it’s OK to use, and often it’s better than using a “pure” neologism.

And that’s why I put “pure” in double quotes: The “purity” itself is not important. Functionality and usability are above all. Sometimes “purity” makes usability better. Sometimes it doesn’t. It’s not an exact science.

I’ll go even further: More often than many people would think, pondering the meaning and choosing a correct translation for a software user interface term may start fruitful conversations about the design of the original software and uncover usability flaws that affect everyone, including the people who use the software in English.

There are thousands of useful bug reports in MediaWiki and in other software projects in which I am involved that were filed by localizers who had translation difficulties. Many of these bugs were fixed, improving the experience for users in English and in all languages.

To sum up:

• Purism shouldn’t be the most important goal, but it should be one of the optional tools that the translator uses.
• Purism is neither absolutely bad nor absolutely good. It can be useful when used wisely in context, case by case.
• Usability should be the most important goal of software localization.
• Usability means usability for all, not just for your colleagues.
• Localizers can improve the whole software in more ways than just translating strings.

# Amir Aharoni’s Quasi-Pro Tips for Translating the Software That Powers Wikipedia, 2020 Edition

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 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.
• “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?

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!

Here’s a story of how I tried to remove a fake story marginally related to COVID-19 from Wikipedia, and, at least for now, achieved the opposite and contributed to its dissemination and perpetuation.

On a BBC-produced podcast (in Russian) I heard a story about Lupe Hernández, a nurse who allegedly invented hand sanitizer. The story was born in a 2012 Guardian article, which was subsequently quoted by viral Facebook posts and a bunch of news sites in Spanish and a bunch of other languages, and even mention in an academic nursing book published by Springer. In the last few months hand sanitizer became more popular than ever, and so the story regained popularity.

When contacted for confirmation, the original Guardian story’s author said that “she couldn’t remember the source, and that her notebooks are in storage facility she currently can’t get to”.

The podcast, as well as a thorough LA Times article, conclude that the whole story is probably an urban legend and that the person probably never existed. No one was even sure whether it’s a woman or a man, even though the original story said “she”.

The podcast did mention that there is a very short Wikipedia article. I proposed it for deletion. The result of the deletion discussion was that the article was kept and renamed to “Lupe Hernández hand sanitizer legend”.

Before it was renamed in the English Wikipedia to be an article about a legend, it was also translated to Spanish and French, as an article about “Guadalupe Hernández”, a female nurse who invented hand sanitizer, even though zero sources say that her name was actually “Guadalupe”. Sure, you can assume that “Lupe” is short for “Guadalupe”, as some imaginative writers did, but why do we do it on Wikimedia sites?

I’m still of the firm opinion that the subject should be completely removed from Wikipedia in all languages, as well as from Wikidata, but there’s only so much I can do about this. If any of you know French or Spanish, can you please make sure the articles in your languages are not too awful, or perhaps consider proposing them for deletion?

# The Persistence of Decision Points in the History of Wikipedia

The Persistence of Poverty, which is today’s episode of NPR’s famous “Indicator” podcast, made me think of how small things that happened long ago in the history of Wikipedia and other Wikimedia wiki sites still affect us, for better or worse.

Here are some examples.

Example one: People didn’t want to have full copies of historical documents on the English Wikipedia, because they are not encyclopedic articles. So they created a whole separate wiki for it, called “Primary Sources Wikipedia”: “ps.wikipedia.org”. It turned out that this would be the URL for the Wikipedia in the Pashto language, which has the ISO 639 code “ps”, so it was renamed to Wikisource, becoming Wikimedia’s first non-Wikipedia wiki. The movement wasn’t even called “Wikimedia” then—the organization was created later. Later, Wiktionary, Wikibooks, WikiCommons, and other projects joined. And Wikisource and all of these other projects are awesome, but now this also has the side effect of having to have some challenging discussions between the Foundation and the community about how non-Wikipedia wikis should be branded in the long term.

Example two: A French Wikipedia editor who is curious about Ancient Egypt wanted to insert Egyptian hieroglyphics into Wikipedia articles, and he happened to know some PHP, so he wrote the Wikihiero extension, which is installed on all the wikis. Because it’s an extension that adds its own wiki syntax, Visual Editor shows a button to insert Hieroglyphics on every page, including the page about Astronomy on Wikiversity, which doesn’t have much to do with Ancient Egypt. This is not bad—this is mostly very good. What is bad is that the Visual Editor doesn’t have a button to insert infoboxes or “citation needed” tags, even though they are far more common than hieroglyphics, because they are implemented as templates and not as PHP, and Visual Editor handles all templates as one generic type of object. (If you are wondering how can this get fixed, the first necessary step in that direction is described on the page Global templates on mediawiki.org.)

Example three: Some people didn’t like that too many wikis are created in new languages and stay inactive, so they wanted a proper way to prove that people plan to be active editors. So they created the “Incubator” wiki, where people would show they are serious by writing the first bunch of articles. For various technical reasons, using it was more difficult than using a usual Wikipedia, but they probably quietly assumed that everybody who wants to create a Wikipedia in a new language is experienced in editing Wikipedia in English or Italian or some other big language, so almost no one ever bothered to improve it. By now, we know that that assumption was tragically wrong: most people who want to create a Wikipedia in a new language are not experienced in editing in other languages, so they are newest and the least experienced editors, but they get the most complicated user interface. (If you are wondering how can this get fixed, see this page on Phabricator.)

Yes, I’m oversimplifying all of these stories for brevity. And I’m not implying any malice or negligence in any of the cases here. These were good people with good intentions, who made assumptions that were reasonable for the time.

It’s just a shame that the problems they created are proving more difficult to fix as the time goes by.

# Yak Shaving, part 2: Wikidata, Busiati col Pesto Trapanese, and Other Slow Food

Some time ago I celebrated a birthday in an Italian restaurant in Haifa, and I saw a pack of pasta of a curious shape on a shelf there. I asked whether they serve it or sell it.

“No”, they told me, “it’s just a display”.

I added the pasta’s name, Busiate, to my shopping list.

I searched for it in a bunch of stores. No luck.

I googled for it and found an Israeli importer of this pasta. But that importer only sell in bulk, in crates of at least 12 items. That’s too much.

And of course, I searched Wikipedia, too. There’s an article about Busiate in the English Wikipedia. There also an article about this pasta in Arabic and in Japanese, but curiously, there’s no article about it in the Wikipedia in the Italian language, nor in the Sicilian language, given that this type of pasta is Sicilian.

So I… did a few things about it.

I Improved the article about Busiate in the English Wikipedia: cleaned up references, cleaned up formatting, and updated the links to references.

I also improved the references and the formatting to the article about Pesto alla trapanese, the sauce with which this pasta is traditionally served.

I also cleaned up the Wikidata items associated with the two articles above: Q48852218 (busiate) and Q3900766 (pesto alla trapanese).

I also translated all the names of the Wikidata properties that are used on these items to Hebrew. I usually do this when I do something with any Wikidata item: I only need to translate these property names once, and after that all the people who use Wikidata in Hebrew will see items in which these properties are used in Hebrew. There are more than 6000 properties, and the number is constantly growing, so it’s difficult to have everything translated, but every little translation makes the experience more completely translated for everyone.

I added references to the Wikidata item about the sauce. Wikidata must have references, too, and not only Wikipedia. I am not enthusiastic about adding random recipe sites that I googled up as references, but luckily, I have The Slow Food Dictionary of Italian Regional Cooking, which I bought in Italy, or more precisely in Esino Lario, where I went for the 2016 Wikimania conference.

Now, a book in Wikidata is not just a book. You need to create an item about the book, and another item about the edition of a book. And since I created those, I create Wikidata items for the dictionary’s original Italian author Paola Gho, for the English translator John Irving, and for the publishing house, Slow Food.

And here’s where it gets really nerdy: I added each of the sauce’s ingredients as values of the “has part” property, and added the dictionary as a reference for each entry. I initially thought that it’s overdone, but you know what?—When we’ll have robot cooks, as in the movie I, Robot, busiati col pesto trapanese will be one of the first things that they will know how to prepare. One of the main points of Wikidata is that it’s supposed to be easy to read for both people and machines.

And since I have a soft spot for regional languages, I also added the sauce’s Sicilian name under the “native label” property: pasta cull’àgghia. The aforementioned Slow Food Dictionary of Italian Regional Cooking actually does justice to the regional part in its title, and gives the names of the different food items in the various regional languages of Italy, so I could use it as a reliable source.

And I translated the Wikipedia article into Hebrew: בוזיאטה.

And I also created the “Sicilian cuisine” category in the Hebrew Wikipedia. A surprisingly large number of articles already existed, filed under “Italian cuisine”: Granita, Arancini, Cannoli, and a few others. Now they are organized under Sicilian cuisine. (I hope that some day Wikipedia categories will be managed more automatically with the help of Wikidata, so that I wouldn’t have to create them by hand.)

Finally, I found the particular issue of the Gazzetta Ufficiale of the Italian Republic, in which busiati col pesto trapanese was declared as a traditional agricultural food product, and I added that issue as a reference to the Wikidata item, as well.

And all of this yak shaving happened before I even tasted the damn thing!

So anyway, I couldn’t find this pasta anywhere, and I couldn’t by it from the importer’s website, but I wanted it really badly, so I called the importer on the phone.

They told me they don’t have any stores in Jerusalem that buy from them, but they suggested checking a butcher shop in Mevaseret Tsiyon, a suburb of Jerusalem. Pasta in a butcher shop… OK.

So I took a bus to Mevaseret, and voila: I found it there!

And I made Busiate, and I made the sauce! It’s delicious and totally worth the effort.

Of course, I could just eat it without editing Wikipedia and Wikidata on the way, but to me that would be boring.

These are the busiate with pesto alla trapanese that I made at home. I uploaded this photo to Wikimedia Commons and added it to the English Wikipedia article as an illustration of how Busiate are prepared. I wonder what do Wikipedians from Sicily think of it.

There is a story behind every Wikipedia article, Wikidata item, and Commons image. Millions and millions of stories. I wrote mine—you should write yours!

# Happy Africa Day: Keyboards for All African Wikipedia Languages

Happy Africa Day!

To celebrate this, I am happy to make a little announcement: It is now possible to write in all the Wikipedias of all the languages of Africa, with all the special letters that are difficult to find on common keyboards. You can do it on any computer, without buying any new equipment, installing any software, or changing operating system preferences. Please see the full list of languages and instructions.

This release completes a pet project that I began a year ago: to make it easy to write in all the languages of Africa in which there is a Wikipedia or an active Wikipedia Incubator.

Most of these languages are written in the Latin alphabet, but with addition of many special letters such as Ŋ, Ɛ, Ɣ, and Ɔ, or letters with accents such as Ũ or Ẹ̀. These letters are hard to type on common keyboards, and in my meetings with African people who would write in Wikipedia in their language this is very often brought up as a barrier to writing confidently.

Some of these languages have keyboard layouts that are built into modern operating systems, but my experience showed me that to enable them one has to dig deep in the operating system preferences, which is difficult for many people, and even after enabling the right thing in the preferences, some keyboards are still wrong and hard to use. I hope that this will be built into future operating system releases in a more convenient way, just as it is for languages such as French or Russian, but in the mean time I provide this shortcut.

The new software released this week to all Wikimedia sites and to translatewiki.net makes it possible to type these special characters without installing any software or pressing any combining keys such as Ctrl or Alt. In most cases you simply need to press the tilde character (~) followed by the letter that is similar to the one you want to type. For example:

• Ɓ is written using ~B
• Ɛ is written using ~E
• Ɔ is written using ~O
… and so on.

Some of these languages are written in their own unique writing systems. N’Ko and Vai keyboards were made by myself, mostly based on ideas from freely licensed keyboard layouts by Keyman. (A keyboard for the Amharic language, also written with its own script, has had keyboards made by User:Elfalem for a while. I am mentioning it here for completeness.)

This release addresses only laptop and desktop computers. On mobile phones and tablets most of these languages can be typed using apps such as Gboard (also in iPhone), SwiftKey (also on iPhone), or African Keyboard. If you aren’t doing this already, try these apps on your phone, and start exchanging messages with your friends and family in your language, and writing in Wikipedia in your language on your phone! If you are having difficulties doing this, please contact me and I’ll do my best to help.

The technology used to make this is the MediaWiki ULS extension and the jquery.ime package.

I would like to thank all the people who helped:

• Mahuton Possoupe (Benin), with whom I made the first of these keyboards, for the Fon language, at the Barcelona Hackathon.
• Kartik Mistry, Santhosh Thottingal (India), Niklas Laxström (Finland), and Petar Petkovich (Serbia), who reviewed the numerous code patches that I made for this project.

This is quite a big release or code. While I made quite a lot of effort to test everything, code may always have bugs: missing languages, wrong or missing letters, mistakes in documentation, and so on. I’ll be happy to hear any feedback and to fix the bugs.

And now it’s all up to you! I hope that these keyboard layouts make it easier for all of you, African Wikimedians, to write in your languages, to write and translate articles, and share more knowledge!

Again, happy Africa day!

The full list of languages for which there is now a keyboard in ULS and jquery.ime:

• Afrikaans
• Akan
• Amharic
• Bambara
• Berber
• Dagbani
• Dinka
• Ewe
• Fula
• Fon
• Ga
• Hausa
• Igbo
• Kabiye
• Kabyle
• Kikuyu
• Luganda
• Lingala
• Malagasy
• N’Ko
• Sango
• Sotho
• Northern Sotho
• Koyraboro Senni Songhay
• Tigrinya
• Vai
• Venda
• Wolof
• Yoruba

# Beggar Old

A strange little childhood memory about Percy Bysshe Shelley and me.

It was 1990 or so. I lived in Moscow and studied in the fifth or six grade in a special school with deepened learning of English, which means that English is taught from the second grade, almost every day, and by good teachers. In case it isn’t clear, it’s very good.

The English teacher asked everyone to choose an English poem, to learn it by heart and to recite it in class. I didn’t quite know what to choose, and my parents suggested I phone a relative who knew English well. He suggested Summer And Winter by Percy Bysshe Shelley:

It was a bright and cheerful afternoon,
Towards the end of the sunny month of June,
When the north wind congregates in crowds
The floating mountains of the silver clouds
From the horizon—and the stainless sky
Opens beyond them like eternity.
All things rejoiced beneath the sun; the weeds,
The river, and the cornfields, and the reeds;
The willow leaves that glanced in the light breeze,
And the firm foliage of the larger trees.

It was a winter such as when birds die
In the deep forests; and the fishes lie
Stiffened in the translucent ice, which makes
Even the mud and slime of the warm lakes
A wrinkled clod as hard as brick; and when,
Among their children, comfortable men
Gather about great fires, and yet feel cold:
Alas, then, for the homeless beggar old!

If it looks very difficult and bleak for a ten year old elementary schools student, then it’s because it is, indeed, difficult and bleak.

I don’t remember how exactly did he get the poem’s text to me. He lived in another neighborhood of Moscow, quite far away. It was 1990, so he didn’t email it, of course. He didn’t photocopy it, either. I remember that it was handwritten. Maybe he sent it as a letter or maybe my parents met him and he gave it to them after manually copying from a book.

I don’t have the slightest idea why did that relative choose this poem. He spoke to me on the phone and explained all the difficult words, but he didn’t explain what’s special about it. Is it famous? Does he love it dearly for some personal reason? Does it have a relevant social message? Maybe—just maybe—we were supposed to choose something related to seasons or weather?

A day later I showed this to my English teacher and she was shocked by the difficulty and offered something much simpler. I don’t remember what it was, but I followed her advice. I did, however, remembered the last line with “alas”, and “beggar old”.

I’d love to speak to this relative some day and ask him what was he thinking.

# Disease of Familiarity, the Flaw of Wikipedia

Originally written as an answer to the question What are some major flaws in Wikipedia? on Quora. Republished here with some changes.

Wikipedia has a whole lot of flaws, and its basic meta-flaw is the disease of familiarity.

It does not mean what you think it means. The disease of familiarity is knowing so much about something that you don’t understand what it is like to not understand it.

I recognized this phenomenon in 2011 or so, and called it The Software Localization Paradox. I later realized that it has a lot of other aspects beyond software localization, so I thought a lot about it and struggled for years with giving it a name. I learned about the term “disease of familiarity” from Richard Saul Wurman, best known as the creator of the TED conference (see a note about it at the end of this post). Some other names for this phenomenon are “curse of knowledge” and “mind blindness”. See also Is there a name for “knowing so much about something that you don’t understand what is it like not to know it”?

Unfortunately, none of these terms is very famous, and their meaning is not obvious without some explanation. What’s even worse, the phenomenon is in general hard to explain because of its very nature. But I’ll try to give a few examples.

Wikipedia doesn’t make it easy for people to understand its jargon.

Wikipedia calls itself “The Free encyclopedia”; what does it mean that it’s “free”? I wrote Wikipedia:The Free Encyclopedia, one of the essays on this topic (there are others), but it’s not official or authoritative, and more importantly, the fact that this essay exists doesn’t mean that everybody who starts writing for Wikipedia reads it and understands the ideology behind it, and its implications. An important implication of this ideology is that according to the ideology of the Free Culture movement, of which Wikipedia is a part, is that some images and pieces of text can be copied from other sites into Wikipedia, and some cannot. The main reason for this is copyright law. People often copy text or images that are not compatible with the policies, and since this is heavily enforced by experienced Wikipedia editors, this causes misunderstandings. Wikipedia’s interface could communicate these policies better, but experienced Wikipedians, who already know them, rarely think about this problem. Disease of familiarity.

Wikipedia calls itself “a wiki”. A lot of people think that it’s just a meaningless catchy brand name, like “Kodak”. Some others think that it refers to the markup language in which the site is written. Yet others think that it’s an acronym that means “what I know is”. None of these interpretations is correct. The actual meaning of “wiki” is “a website that anyone can edit”. The people who are experienced with editing Wikipedia know this, and assume that everybody else does, but the truth is that a lot of new people don’t understand it and are afraid of editing pages that others had written, or freak out when somebody edits what they had written. Disease of familiarity.

The most common, built-in way for communication between the different Wikipedians is the talk page. Only Wikipedia and other sites that use the MediaWiki software use the term “talk page”. Other sites call such a thing “forum”, “comments”, or “discussion”. (To make things more confusing, Wikipedia itself occasionally calls it “discussion”.) Furthermore, talk pages, which started on Wikipedia in 2001, before commenting systems like Disqus, phpBB, Facebook, or Reddit were common, work in a very weird way: you need to manually indent each of your posts, you need to manually sign your name, and you need to use a lot of obscure markup and templates (“what are templates?!”, every new user must wonder). Experienced editors are so accustomed to doing this that they assume that everybody knows this. Disease of familiarity.

A lot of pages in Wikipedia in English and in many other languages have infoboxes. For example, in articles about cities and towns there’s an infobox that shows a photo, the name of the mayor, the population, etc. When you’re writing an article about your town, you’ll want to insert an infobox. Which button do you use to do this? There’s no “Infobox” button, and even if there were, you wouldn’t know that you need to look for it because “Infobox” is a word in Wikipedia’s internal jargon. What you actually have to do is Insert → Template → type “Infobox settlement”, and fill a form. Every step here is non-intuitive, especially the part where you have to type the template’s name. Where are you supposed to know it from? Also, these steps are how it works on the English Wikipedia, and in other languages it works differently. Disease of familiarity.

And this brings us to the next big topic: Language.

You see, when I talk about Wikipedia, I talk about Wikipedia in all languages at once. Otherwise, I talk about the English Wikipedia, the Japanese Wikipedia, the Arabic Wikipedia, and so on. Most people are not like me: when they talk about Wikipedia, they talk about the one in the language in which they read most often. Quite often it’s not their first language; for example, a whole lot of people read the Wikipedia in English even though English is their second language and they don’t even know that there is a Wikipedia in their own language. When these people say “Wikipedia” they actually mean “the English Wikipedia”.

There’s nothing bad in it by itself. It’s usually natural to read in a language that you know best and not to care very much about other languages.

But here’s where it gets complicated: Technically, there are editions of Wikipedia in about 300 languages. This number is pretty meaningless, however: There are about 7,000 languages in the world, so not the whole world is covered, and only in 100 languages or so there is a Wikipedia in which there is actually some continuous writing activity. In the other 200 the activity is only sporadic, or there is no activity at all—somebody just started writing something in that language, and a domain was created, but then the first people who started it lost interest and nobody else came to continue their work.

This is pretty sad because it’s frequently forgotten that a whole lot of people cannot read what they want in Wikipedia because they don’t know a language in which there is an article about what they want to learn. If you are reading this post, you have the privilege of knowing English, and it’s hard for you to imagine how does a person who doesn’t know English feel. Disease of familiarity: You think you can tell everybody “if you want to know something, read about it in Wikipedia”, but you cannot actually tell this to most people because most people don’t know English.

The missed opportunity becomes even more horrific when you realize that the people who would have the most appropriate skills for breaking out of this paradox are the people who are least likely to notice it, and the people who are hurt by it the most are the least capable of fixing it themselves. Think about it:

• If you know, for example, Russian and English, and you need to read about a topic on which there is an article in the English Wikipedia, but not in Russian, you can read the English Wikipedia, and it’s possible that you won’t even notice that an article in Russian doesn’t exist. Unless you exercise mindfulness about the issue, you won’t empathize with people who don’t know English. To break out of this cycle, one can practice the following:
• Always look for articles in Russian first.
• Dedicate some time every week to translating articles. (See How does Wikipedia handle page translation?)
• When you talk to people in your language, don’t assume that they know English.
• A person who doesn’t know English is just stuck without an article, and there’s not much to do. It’s possible that you don’t even know that the article you need exists in another language. And maybe you cannot even read the user manual that teaches you how to edit. What can you do?
• Try to be bold and ask your friends who do know English to translate it for you and publish the translation for the benefit of all the people who speak your language.
• (Of course, there’s the solution of learning English, but we can’t assume that it works. Evidently, there are billions of people who don’t know English, and they won’t all learn English any time soon.)

(In case it isn’t clear, you can replace “English” and “Russian” in the example above with any other pair of languages.)

It’s particularly painful in countries where English, French, or Portuguese is the dominant language of government and education, even though a lot of the people, often the majority, don’t actually know it. This is true for many countries in Africa, as well as for Philippines, and to a certain extent also in India and Pakistan.

People who know English have a very useful aid for their school studies in the form of Wikipedia. People who don’t know English are left behind: the teachers don’t have Wikipedia to get help with planning the lessons and the students don’t have Wikipedia to get help with homework. The people who know English and study in English-medium schools have these things and don’t even notice how the other people—often their friends!—are left behind. Disease of familiarity.

Finally, most of the people who write in the 70 or so most successful Wikipedias don’t quite realize that the reason the Wikipedia in their language is successful is that before they had a Wikipedia, they had had another printed or digital encyclopedia, possibly more than one; and they had public libraries, and schools, and universities, and all those other things, which allowed them to imagine quite easily how would a free encyclopedia look like. A lot of languages have never had these things, and a Wikipedia would be the first major collection of educational materials in them. This would be pretty awesome, but this develops very slowly. People who write in the successful Wikipedia projects don’t realize that they just had to take the same concepts they already knew well and rebuild them in cyberspace, without having to jump through any conceptual epistemological hoops.

Disease of familiarity.

It’s hard to explain this.

I unfortunately suspect that very few, if any, people will understand this boring, long, and conceptually difficult post. If you disagree, please comment. If you think that you understand what I’m trying to say, but you have a simpler or shorter way to say it, please comment or suggest an edit (and tell your friends). If you have more examples of the disease of familiarity in Wikipedia and elsewhere, please speak up.

Thank you.

(As promised above, a note about Richard Saul Wurman. I heard him introduce the “disease of familiarity” concept in an interview with Debbie Millman on her podcast Design Matters, at about 23 minutes in. That interview was one of this podcast’s weirdest episodes: you can clearly hear that he’s making Millman uncomfortable, and she also mentioned it on Twitter. This, in turn, makes me uncomfortable to discuss something I learned from that interview, but I am just unable to find any better terminology for the phenomenon in question. If you have suggestions, please send them my way.)

Disclaimer: I’m a contractor working with the Wikimedia Foundation, but this post, as well as all my other posts on the topic of Wikimedia, Wikipedia, and related projects, are my own opinions and do not represent the Wikimedia Foundation.

# Why Did I Leave Quora, Why It Is Not Such a Big Deal, and Why Do I Nevertheless Hope to Come Back

This post is sad and angry. I don’t mention any names, but some people may read it and identify themselves here. Here’s my request to these people: I hope that this doesn’t hurt you personally. It’s not my intention to hurt anyone personally. All people have to do their jobs; sometimes they are happy about what they do despite some people’s complaints, sometimes they aren’t happy, but do it anyway because they need to pay bills, or because that it’s necessary for some kind of greater good. I totally get it. There’s a certain chance that I’ll meet some of you online or in real life. If this ever happens, I hope you don’t feel embarrassed or intimidated. I’ll be happy to meet you and I promise to be friendly. Thanks for understanding.

I used to be a prolific writer on the question and answer website Quora. I was even named a “Top Writer” four times. Sadly, in 2018 this once-fine website ruined itself.

The problematic signs were there even earlier, but the true catastrophe began with the “Links” feature. This feature adds links to articles on other websites to the Quora feed. Before this feature’s introduction the feed consisted mostly of questions and answers, as one would expect from, you know, a questions and answers website.

The articles and the websites shown as “Links” in the feed are selected automatically by Quora’s software. How does this software work is a mystery. There appears to be some intention to show things that are related to the topics that the user follows, but it also suggests unrelated topics. Sometimes they are labelled “Topic you might like”. Sometimes they aren’t labelled at all:

There’s no way to select a website to follow and see links from. There is a way to mute websites, but other sites will be shown instead.

There’s also no way to remove all the Links from the feed completely. By popular demand from Quora users, a volunteer made a browser extension called “Qure” that does it, but it only works on the web and not on the Quora mobile app.

The Link items in the feed look almost exactly like questions, which is severely distracting, and feels out of place. Quora staff people who work on this feature know it—”the links feel out of place” is a direct quote from a staff person. They know that many users dislike them, but they choose to show them anyway. “We’ll show links less to people who don’t like them” is also a direct quote from a staff person.

Let this sink in: They know that some people don’t like the links, and they show them to these people anyway. My logic—I won’t even bother calling it “ethics”—tells me that when you know that a person doesn’t like a thing, you don’t show that thing to that person at all unless you have a particularly good reason and you can explain it.

Another problematic feature that Quora introduced in 2018 is “Share”. This sounds like a sensible thing to have on any modern website, but on Quora it has a somewhat different meaning. “Sharing” on Quora means putting an item in your followers’ feed with a comment.

This is similar to retweeting with a comment on Twitter. It works fairly well on Twitter, but Quora is not Twitter. In Twitter everything is limited to 280 characters—the tweets and the comments on retweets. On Quora answers can and should be longer, but the comments are short, and this feels imbalanced.

What’s worse, even though Quora says that the comments on shared items “provide additional insight“, they are actually rather pointless. In fact, many of them are not even really written by people, but filled semi-automatically: “This is interesting“, “This is informative”, “Great summary”, “I recommend reading this“, etc. Those that are actually written by humans are not much better, for example: “H.R. has been a wonderful teacher and excellent writer. Since joining Quora last year I’ve latched on to his brilliance – he’s earned his place firmly”. This says nothing substantial that couldn’t be expressed by simply upvoting the writer’s answer.

And then there are the items that are questions or answers, but that are shown to me on my feed for mysterious reasons: They are categorized under a topic I don’t follow, they are written by users that I don’t follow, and they weren’t even upvoted or shared by users that I do follow. They are just totally, completely unrelated to me.

Occasionally they are labelled as “Topic you might like” or “Author you might like”, but sometimes they don’t even carry this label.

It’s difficult to discuss this feature because unlike “Share” and “Links” it doesn’t even have a name. It’s just… random stuff that I didn’t ask to see, and that appears in my feed. In this blog post I’ll call it Nonsense. It’s not a nice name, but that’s what it is. (I really want to know this feature’s real name. It surely has one. If you are on Quora staff, please tell me what it is. I won’t reveal your identity.)

I would possibly understand showing this Nonsense to new users: Quora may want to suggest you stuff to follow to get you hooked. But I’ve had the account for seven years, I follow lots of people and topics, I visit the site several times a day, and I know very well what I want.

What’s worse, Nonsense items are shown to me while many items written by people I do follow are not. I followed people on Quora because their personality or knowledge genuinely interested me. To me, “Follow” means that I’m interested in seeing stuff written by these people. But Quora decided to disregard my specific request, and to show me Nonsense instead.

There’s no way to run away from Link items, from Share items, and from Nonsense items. Quora has a Mute feature, but for the most part it does more harm than good:

• When you mute a Link item it mutes a particular link source, for example New York Times or Breitbart (yes, both are available), but when you mute one source, other sources are shown instead and there appears to be no end to it.
• When you see an answer on a topic you don’t follow, you can mute that topic, but this (probably) means that if an answer is written in this topic by a user that you do follow, you won’t see it. This is often not what one wants. For example, “Entertainment” is a topic on which answers are often shown to me, even though I don’t follow it. I don’t want to see this random answers, but if a user I follow posts an answer in a question for which this is one of the topics, I’d be OK with seeing it.
• When you see an “Author you might like”, and you don’t actually like that author, you can mute them. As above, this is not necessarily what I want: If that author happens to write an answer on a topic I follow, I’ll be OK with seeing it. I just don’t want to see that author’s answers when they are completely unrelated to me, but this is a feature, and there’s no way to get rid of it.

When I first saw the Links in February 2018, I was immediately appalled: What is this thing that is neither a question nor an answer?! When I saw that I cannot remove them from my feed, I pretty much immediately decided to stop using the site. It was clear to me that something is badly wrong.

Even thought I deleted my Facebook account in 2015, I created a new one some time after the links were introduced, just so that I could join the private Quora Top Writers Feedback group. For several months I tried talking to the Quora staff people in that group and understand: Why do the links even exist? Why are they so random and useless? Why are pointless items shown to me? I got almost zero substantial replies.

I intentionally came back to sincerely using Quora, thinking that the algorithms will learn my behavior, and show me more relevant links, or no links at all. This didn’t work, of course, and Quora became even worse when the awful Share and Nonsense features were added, so in June 2018 I stopped posting there almost completely.

After some more time, the Facebook group’s moderator didn’t like my questions about these unfortunate features, and removed me from the group, too. The explanation was that they were repetitive, which is understandable; what is less understandable is that instead of removing me from the group they could try answering the questions. They didn’t. They did suggest sending my complaints to a particular email address for Top Writers. I did it, and I received no reply.

So that’s it, I guess.

A legitimate question arises: Could I use Quora without the feed? Not really, because the best thing about Quora was that before the disastrous 2018 changes it showed me answers that interest me and questions that need answers on topics about which I know something. Without this, the site is not that useful. It moved to being oriented much more towards readers who are prone to click on clickbait and to writers who are local Quora “stars”. I don’t belong to either group.

(Before I go into the last conclusions, I should mention one unrelated and very positive thing that Quora did in 2018: Expansion of its internationalization efforts. For years, Quora used to be explicitly English-only. Later, Quora introduced sites in several new languages, among them Spanish, German, Hindi, Portuguese, Indonesian, and French. It also added an answer translation feature, which, while not yet implemented perfectly, is a step in a very good direction. I hope that it gets developed further and doesn’t get killed.)

I have a bit of a price to pay for publishing this blog post. I probably won’t be a top writer again (this came with pretty nice swag). I might be banned; not that it matters, because I plan to deactivate the account anyway. I may run into Quora staff people at professional conferences, and things may get awkward (see the top of this answer—I do hope to meet you, and I hope that it won’t get too awkward).

But at the same time… it’s not actually a big deal. Even though before 2018 Quora was a really nice place to ask my questions and to answer questions for which people need an answer, it is nowhere near being a truly essential site like Wikipedia. Stopping to read and write there every day allowed me to focus better on family and work, and also to revive some old neglected projects, such as translating Wikipedia articles or proofreading Gesenius’ Hebrew Grammar at Wikisource.

All that said, yeah, I’d probably be happy to come back. The web does need a good question and answer site, with relevant topics, with pleasant design, and with good moderation. Quora used to be such a site. It is no longer such a site, with or without me. It can easily go back to being one. However, this will only happen when it becomes possible to remove Links, Shared items, and Nonsense from the feed.

A couple of last conclusions:

1. On a website that has the characteristics of being a social network or a writers community, users need to be empowered somehow. It’s not easy, and it has costs, but when it’s done right, it’s worth it. Wikipedia empowers its users ridiculously: on no other site can the users edit the site’s CSS and JavaScript (not all users, but a lot of them). Reddit is not as transparent as Wikipedia, but it’s quite empowering as well: subreddit moderators can pressure the site’s management. The results of this pressure may be unpleasant and controversial, but it’s nevertheless good to have balances. Quora users are not empowered at all. It gives the company a lot of control, but is it actually good?
2. Some people enjoy random weird algorithmically-selected stuff, and some people don’t. I hate the Links, and the Nonsense items, and a lot of other users hate them, but some people are fine with them. And that’s OK. That’s what preferences are for.