Got your attention with that provocative title? Good.
No, I absolutely don’t want Wikipedia to be less Free in terms of copyright and licenses and all that. I wrote the Wikipedia:The Free Encyclopedia essay on the English Wikipedia, and I still totally support it.
With that out of the way, there’s another aspect of “Free” in the Wikipedia world, which is not frequently discussed, and I’ve just realized that it’s kind of important.
What is the most translated book in the world? The Bible, of course. Why is it the most translated book? Because there are people who are emotionally attached to it, who want to spread it around the planet, and who are willing to donate money to organizations who translate and distribute it, and these organizations are actually good at what they do.
It’s not so important that it’s the Bible that happens to be the most translated book. If it wasn’t the Bible, it would be something else: some other religious book, or The Declaration of Human Rights, or The Communist Manifesto, or Romance of the Three Kingdoms, or Twelfth Night, or The Little Prince. I mean, what is the Bible? It’s a book; it has a beginning and an end. Sure, different Christian confessions can argue about the Apocrypha, the sequence of the books, the inclusion of some verses, the translation of some theologically significant words, and so on, but this is also completely unimportant for our issue; most of the Bible is the same in all confessions.
Now, because I love translation, I quite often read about organizations who engage in translating the Bible: Wycliffe, SIL, JW, Latter-Day Saints, etc. Wycliffe, for example, can publish an image like this one:
They can speak about “a full Bible” and to give a count of how many languages have one, because they know what the Bible is.
It’s not about religion. You could just as well make such a report about Alice’s Adventures in Wonderland or about Things Fall Apart. And you don’t even have to make such a report about these famous, iconic books: I’m sure that in the marketing department of every Hollywood studio there are people who make dozens of reports like this about translating movies every year. Like books, movies have a beginning and an end. So it’s really not about the Bible; the Bible just happens to be one book that attracts exceptional fame and emotion, so it’s useful as an example.
But could you make such a report about Wikipedia? Not quite.
That’s because we don’t really know what Wikipedia is. Unlike a book, it doesn’t have a clear beginning and an end. In languages that have an active Wikipedia editing community, it is changing so frequently, and so differently from other languages, that we can’t define what is “a Wikipedia” in a way that “translating Wikipedia” would mean “writing all the same things, just in another language”. You could perhaps say this about a single Wikipedia article, and you’d have challenges even with that, but you can’t say it about a whole Wikipedia.
We can make technical statements: “There is a Wikipedia in English; There is a Wikipedia in Japanese; There is a Wikipedia in Zulu; There is a Wikipedia in Hungarian”. For each of these languages, there is a *.wikipedia.org domain, and it leads to a website that has the same name and the same puzzle globe logo, and runs on more or less the same software platform. There is some overlap in the articles that each of these sites has, but defining this overlap is too elusive.
Having a domain does not necessarily mean that there is a full-fledged Wikipedia in a language. A Wikipedia needs articles and readers. For example: Intuitively, we can say that while the Zulu Wikipedia is not worthless, it is not nearly as useful to Zulu speakers as the Hungarian Wikipedia is to Hungarian speakers, even though both languages have a comparable number of speakers. The one in Zulu has much fewer articles and readers than the one in Hungarian.
So does it mean that to be useful, the Zulu Wikipedia has to translate all the articles from the Hungarian Wikipedia, or the English one? No. I have proof, which is also based on my intuition and not on data, but I doubt that anyone will reject it, even though it’s somewhat paradoxical. I’d argue that the Hungarian Wikipedia is more or less as useful for Hungarian speakers as the English Wikipedia, even though it has much fewer articles. Within the country of Hungary, the Hungarian Wikipedia gets more than twice the pageviews than the English Wikipedia does. This probably means that the Hungarian Wikipedia editors are quite good at guessing what things do other Hungarian speakers want to read about, and in writing articles about them, so Hungarian speakers are usually able to find lots of things they need there without having to search for it in another language (or giving up because they don’t know any other language). Unfortunately, the Zulu Wikipedia is not there yet. I know a few Zulu Wikipedians and they are wonderful, but it will take some time and effort to make the Zulu Wikipedia into an online encyclopedia that is as useful and robust as the one in Hungarian, or Hebrew, or English.
But still, even though it’s based on some data, all of that is mostly intuition. It all sounds correct, but we have no precisely defined way to measure it comprehensively. We can precisely answer the question “how many languages have the Bible” or “how many languages have Winnie-the-Pooh” because we know what these books are, but we cannot precisely and usefully answer the question “how many languages have a Wikipedia”, because we don’t know what “a Wikipedia” is.
We can know this about a certain small part of Wikipedia: the localization of its software platform, MediaWiki. The list of strings to translate is well-defined. It often changes, because the software is being actively developed, but on any given day you can easily get a report that says: “Language X has Y% of the software needed to run Wikipedia”. That’s because the software is largely the same in all the languages (with some caveats); in other words, it has a beginning and an end.
A screenshot of a part of the report. Good work, translators to Arabic, Belarusian, German, Persian, French, Macedonian, Norwegian Bokmål, Dutch, Russian, and Turkish! (Also Hebrew, but a lot of that is done by yours-truly, so it’s weird to praise myself.)
OK, but the software is not that useful without the content. So why don’t we similarly define what articles must exist in a Wikipedia to determine that it is a Wikipedia, and that it’s actually useful?
Well, because of that other subtle freedom: The community of Wikipedia writers in every language is free to decide which articles they want to write, and what is encyclopedically notable or non-notablefor them. This freedom is generally a Good Thing: People who live in different countries and speak different languages have different needs and interests, and no one in their right mind should want to enforce a list of what Wikipedia articles must exist on people from another culture.
But what if we could suggest such a list? In a way, we already do: There’s the somewhat-famous List of articles every Wikipedia should have. That list has a bunch of problems, however.
It is manually curated by… some people, with whose Wikipedia usernames I’m not familiar. I have nothing against them; the work they do may be very good, but I don’t feel like they are widely recognized as an authority. I might be wrong.
In addition, how is this list used structurally? What can you do with it, other than just read it? There are some bots and Wikidata queries that measure how well does the Wikipedia in every language cover the topics on that list. For example, there’s an automatic report of which articles from this list are missing in each language. While these tools may be convenient for experienced Wikipedians, I doubt that they are good at encouraging masses of potential editors to improve the content coverage in their language. (Again, do correct me if I’m wrong.)
Finally, it is just one such list. While the articles on it may indeed be important for all of humanity, people who speak different languages will need additional articles about things that interest them. Of course, this list doesn’t try to enforce its own exclusivity, and people are free to create additional custom lists that match their cultural and regional needs… but that brings us back to the problem: Sure, freedom to make your own lists is good and essential, but if people in every language have to reinvent the wheel and do it manually, it’s difficult and inefficient. And if it’s not done systematically and uniformly for all languages, you can only use intuition and not precise measurement to decide whether a language really has a Wikipedia or not.
And that, I’d say, is too much freedom. Wikipedia should be a bit less free in this regard. I’ll repeat: No, not to force people to write about things that other people in another country decided that they must write, but to have a global way to decide on a task list, of what should be done and what was done already. A nudge.
Do I have anything to suggest as a fix to this problem? Not much, except identifying it: We cannot usefully define a Wikipedia, and we can only know it when we see it.
Still, what I can think about is a two-part approach. The first part is formulating a global community policy to determine at which point does a Wikipedia become really useful. Don’t call it “rules”; call it “recommended guidelines for measurable sustainable growth”. Sounds bureaucratic in the style of U.N. and E.U., but read it carefully—I actually mean it. If done well, it might work. By “work”, I mean “get Wikipedia in all languages to grow and become more useful for people who speak these languages”.
It would include things such as:
A global list of articles that every language should have, with globally important topics. Notice: should, not must! The “List of articles every Wikipedia should have” can probably be a starting point, but the discussion about forming and updating it should probably be wider, more structured, and endorsed by some recognized community body, such as the Board or the Language committee.
A local list of articles that a language should have. The list itself will be different in each language, but the method to build it will be the same, so that languages can be compared.
The expected length of each article and some heuristic quality markers: section headings, references, links, etc.
An expected number of how many people write these articles, proportinally to the number of people who speak the language.
An expected number of how many people read these articles, proportinally to the number of people who speak the language (this can be measured by counting pageviews in regions where each language is spoken).
A method to update these lists and the policy itself.
And the second part is building structured, integrated technical tools that help implement that policy:
Entering the lists into a structured database (that is, not a free-form wiki page).
Tracking the progress of the Wikipedia in each language from being just a domain with some test articles fresh out of the Incubator to being a full-fledged Wikipedia that people regularly edit, read, and rely on. “Tracking” means auto-generated tables, charts, and progress bars.
Nudging people to come in and contribute to achieving that goal for their language by writing or translating articles, improving (“wikifying”) existing articles, and so on.
Why would people want to coöperate with these rules and use them? Maybe they won’t, and that’s OK. But from my years of talking to people from all over the world who want to create a Wikipedia in their language, or who want to develop the one that they have, I repeatedly heard that what they want is a Wikipedia, mostly like the one in big languages such as English, French, Indonesian, or Russian, but in their language. It’s unreasonably difficult to do it without first defining what a Wikipedia is, and doing it in a way that relies on definitions and guidelines and not only on intuition and freedom.
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.
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.
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.
The translatewiki.net website hosts many projects to translate beyond stuff related to Wikipedia. It hosts such respectable Free Software projects as OpenStreetMap, Etherpad, MathJax, Blockly, and others. Also, not all the MediaWiki extensions are used on Wikimedia projects. There are plenty of extensions, with thousands of translatable messages, that are not used by Wikimedia, but only on other sites, but they use translatewiki.net as the platform for translation of their user interface.
It would be nice to translate all of it, but because I don’t have time for that, I have to prioritize.
On my translatewiki.net user page I have a list of direct links to the translation interface of the projects that are the most important:
Core MediaWiki: the heart of it all
Extensions used by Wikimedia: the extensions on Wikipedia and related sites. This group is huge, and I prioritize it further; see below.
MediaWiki Action Api: the documentation of the API functions, mostly interesting to developers who build tools around Wikimedia projects
Wikipedia Android app
Wikipedia iOS app
Installer: MediaWiki’s installer, not used on Wikipedia because MediaWiki is already installed there, but useful for people who install their own instances of MediaWiki, in particular new developers
Intuition: a set of tools, like edit counters, statistics collectors, etc.
Pywikibot: a library for writing bots—scripts that make useful automatic edits to MediaWiki sites.
I usually don’t work on translating other projects unless all the above projects are 100% translated to Hebrew. I occasionally make an exception for OpenStreetMap or Etherpad, but only if there’s little to translate there and the untranslated MediaWiki-related projects are not very important.
Priorities, part 2
So how can you know what is important among more than 18,000 messages from the Wikimedia universe?
Start from MediaWiki most important messages. If your language is not at 100% in this list, it absolutely must be. This list is automatically created periodically by counting which 600 or so messages are actually shown most frequently to Wikipedia users. This list includes messages from MediaWiki core and a bunch of extensions, so when you’re done with it, you’ll see that the statistics for several groups improved by themselves.
Now, if the translation of MediaWiki core to your language is not yet at 18%, get it there. Why 18%? Because that’s the threshold for exporting your language to the source code. This is essential for making it possible to use your language in your Wikipedia (or Incubator). It will be quite easy to find short and simple messages to translate (of course, you still have to do it carefully and correctly).
Some technical notes
Have you read the general localization guide for Mediawiki? Read it again, and make sure you understand it. If you don’t, ask for help! The most important section, especially for new translators, is “Translation notes”.
A super-brief list of things that you should know:
Many messages use symbols such as ==, ===, [[]], {{}}, *, #, and so on. This is wiki syntax, also known as “wikitext” or “wiki markup”. It is recommended to become familiar with some wiki syntax by editing a few pages on another wiki site, such as Wikipedia, before translating MediaWiki messages at translatewiki.
“[[Special:Homepage]]” adds a link to the page “Special:Homepage”. “[[Special:Homepage|Homepage]]” adds a link to the page “Special:Homepage”, but it will be displayed as “Homepage”. In such cases, you are usually not supposed to translate the text before the | (pipe), but you should translate the text after it. For example, in Russian: “[[Special:Homepage|Домашняя страница]]”. When in doubt, check the documentation in the sidebar.
$1, $2, $3: These are known as parameters, placeholders, or variables. They are replaced in run time, usually by numbers of names. Copy them as they are, and put them in the right place in the sentence, where it is right for your language. Always check the documentation in the sidebar to understand with what will they be replaced.
If you see something like “$1 {{PLURAL:$1|page|pages}}” in a translatable message, this means that the word will be shown according to the value of the variable $1. Note that you must not change the “PLURAL:$1” part, but you must translate the “page|pages” part.
If you see something else in curly brackets, it’s probably a “magic word”. Check the documentation to understand it. You usually don’t translate the thing in the beginning, such as {{SITENAME, {{GENDER, etc., but you sometimes need to translate things towards the end. See the localization guide for full documentation!
Learn to use the project selector at the top of the translation interface. Projects are also known as “Message groups”. For example, each extension is a message group, and some larger extension, such as Visual Editor, are further divided into several smaller message groups. Using the selector is very simple: Just click “All” next to “Message group”, and use the search box to find the component that you want to translate, such as “Visual Editor” or “Wikibase”. Clicking on a message group will load the untranslated messages for that group.
The “Extensions used by Wikimedia” group is divided into several more subgroups. The important one is “Extensions used by Wikimedia – Main”, which includes the most commonly used extensions. Other subgroups are:
“Advanced”: extensions that are used only on some wikis, or are useful only to administrators and other advanced users. This should be the first subgroup you translate after you complete the “Main” subgroup.
“Fundraising”: extensions used for collecting donations for the Wikimedia Foundation.
“Legacy”: extensions that are still installed on Wikimedia sites, but are going to be removed. You can most likely skip this subgroup completely.
“Media” includes advanced tools for media files curating and uploading, especially on Wikimedia Commons.
“Technical”: this is mostly API documentation for various extensions, which is shown on the ApiHelp and ApiSandbox special pages. It is very useful for developers of gadgets, bots, and other software, but not necessary for other users. This group also includes several other very advanced extensions that are used only by a few people. You should translate these messages some day, but it’s OK to do it later.
“Upcoming”: these are extensions that are not yet widely installed on Wikimedia sites, but are going to be installed soon. Translating them is a pretty good idea, because they are usually very new, and may include some confusing messages. The earlier you report these confusing messages to the developers, the better!
“Wikivoyage”: extensions used only on Wikivoyage sites. Translate them if there is a Wikivoyage site in your language, or if you want to start one.
There is also a group called “EXIF Tags”. It’s an advanced part of core MediaWiki. It mostly includes advanced photography terminology, and it shows information about photographs on Wikimedia Commons. If you are not sure how to translate these messages, ask a professional photographer. In any case, it’s OK to do it later, after you completed more important components.
Getting things done, one by one
Once you have the most important MediaWiki messages 100% and at least 18% of MediaWiki core is translated to your language, where do you go next?
I have surprising advice.
You need to get everything to 100% eventually. There are several ways to get there. Your mileage may vary, but I’m going to suggest the way that worked for me: Complete the easiest piece that will get your language closer to 100%! For me this is an easy way to remove an item off my list and feel that I accomplished something.
But still, there are so many items at which you could start looking! So here’s my selection of components that are more user-visible and less technical. The list is ordered not by importance, but by the number of messages to translate (as of October 2020):
Vector: the default skin for desktop and laptop computers
Minerva Neue: the skin for mobile phones and tablets
Babel: for displaying boxes on user pages with information about the languages that the user knows
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)
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.
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?
And if you think I’m badly wrong about it all, please do tell me, too.
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.
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”.
This answer didn’t satisfy me.
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.
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.
My wife and my son loved it.
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!
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.
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:
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.
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.
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:
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.
Aharoni in Unicode 