There’s a popular podcast produced by the New York Times: Hard Fork. It talks about technology, and since a lot of people these days find it difficult to talk about technology without mentioning “AI”, the two Hard Fork hosts make two disclaimers in almost every episode: That the New York Times is suing OpenAI, and that the boyfriend of one of the hosts works for Anthropic, which makes the Claude conversation simulator.
There is, however, another thing that is common to both the New York Times and Anthropic, and it has nothing to do with “AI”. It’s that Android apps made by these two companies have the same bug, and this bug is mindbogglingly silly.
This bug makes countless Android apps partially or completely broken for anyone whose phone interface is set to Hebrew, Arabic, Persian, Urdu, or any other right-to-left (RTL) language. The most frustrating part? This widespread problem, which affects hundreds of millions of users globally, can be fixed by changing one line of code.
The Problem: When English Apps Go RTL
I use my Android phone with a Hebrew interface because, well, Hebrew is my language. I don’t expect all English-language apps to support Hebrew. The New York Times, for example, publishes almost everything in English, and that’s OK. The Claude app’s user interface is in English and hasn’t been localized to Hebrew, at least yet, and that’s not too bad either. I know English, and when I choose an English-language app, I just want it to work well in English.
What’s not fine is when these apps break because they’re trying to adapt to right-to-left languages when they have no business doing so. Apps try to do this because they see that my phone asks for Hebrew user interface. They are trying—and failing. The results are grim.
In the NYT Cooking app, recipe reviews get hidden behind star ratings, English text awkwardly aligns to the right, and ellipsis marks appear on the wrong side of photo captions. The app becomes harder to use despite being entirely in English.
The Claude AI app suffers from similar problems—interface elements flip inappropriately, making the English-language interface confusing and sometimes unusable.
Perhaps most dramatically, in 2019, I captured a screenshot from the Delta Air Lines app that showed a flight appearing to go from Atlanta to JFK when it was actually going from JFK to Atlanta.
While Delta seems to have fixed its app since 2019, it illustrates how RTL bugs can be genuinely misleading.
The Root Cause: Android Studio’s Default Behavior
The real culprit isn’t individual app developers—it’s Google’s Android development ecosystem. When developers create new Android apps using Android Studio, the most popular development tool, the default configuration includes android:supportsRtl="true" in the app’s configuration file, AndroidManifest.xml.
This setting tells Android to automatically flip the app’s layout for RTL languages. Google wants to encourage and simplify RTL language support for developers, but it goes too far: developers don’t even think that they need to do anything, and the result is broken.
The irony is that we’re living in an age of incredibly sophisticated AI and machine learning, yet this simple localization bug—which has nothing to do with advanced computer science—causes daily frustration for hundreds of millions of people.
The Scale of the Problem
This isn’t a niche issue. Consider the numbers:
Arabic: more than 400 million speakers
Urdu: more than 200 million speakers
Persian: more than 110 million speakers
Hebrew speakers: about 9 million speakers
And there are other RTL languages: Punjabi, Uyghur, Yiddish, and more.
We’re talking about hundreds of millions of people who experience degraded app performance through no fault of their own. They’re not asking for their native language support—they just want English apps to work properly when their phone’s system language happens to be RTL. Because of problems like this, many of those people choose to use their phones in English and get all the apps in English, even though many of them don’t actually know English very well.
So please don’t tell me to switch my phone to English—it’s not actually a solution.
There’s another bitter irony in this situation. Hebrew speakers, Arabic speakers, and Persian speakers, are often divided by geopolitics and conflict. Yet we’re all united by the same stupid software bugs in the support for the languages that we speak, read, write, and love.
I’ve spoken with Palestinians, Saudis, Iranians, and Pakistanis about this issue. We all face the same broken apps, the same UI frustrations, the same feeling of being an afterthought in software design. Perhaps instead of fighting each other, we should unite in fighting these bugs—with code and constructive feedback, of course.
My Quixotic Quest for Fixes
I’ve become something of a Don Quixote in this fight, reporting this bug to dozens of companies. The responses have been telling:
Most companies, including Anthropic: Complete silence.
Some companies, including The New York Times, as well as Dave & Busters, italki, Citizens Bank, and many, many others: Promised to fix it, but didn’t.
A few apps, like Dunkin’ Donuts and Podcast Addict, actually got fixed as a result or my emails. ❤️
One company, Drive Less, a local Rhode Island biking app, not only fixed it, but also sent me a $20 gift card. ❤️❤️
One more company, the Massachusetts Bay Transportation Authority, also known as the MBTA or “the T”, published the source code of its Android app on GitHub under a Free Software license, so I sent a fix, and they quickly merged it and released an update!¹ ❤️❤️❤️
Despite the few positive examples at the end of this list, the pattern is clear: this is a fixable problem, but most companies don’t prioritize it because it doesn’t affect English-speaking decision-makers.
The Absurdly Simple Solution
Here’s the fix that would solve this problem in almost all affected apps:
In the AndroidManifest.xml file, change the line android:supportsRtl="true" to android:supportsRtl="false".
That’s it. One line.
This tells Android: “This app doesn’t support RTL layouts, so don’t try to flip anything.” The app will continue working normally in English, regardless of the user’s system language.
Apps that genuinely want to support RTL languages—which is commendable!—should keep the setting as "true", but then properly implement RTL layouts with appropriate testing and design considerations.
How to Make an Even Bigger Change
While individual app developers can fix it in their products, this is not really scalable. The real, big solution needs to happen at the platform level. Most importantly, Android Studio should change its defaults: New projects shouldn’t include RTL support unless developers explicitly opt in. I’m not sure how to fix it in all the existing apps, but at least in theory, it’s possible.
So What Can You Do
If you’re an Android developer, check your app’s RTL behavior. If you’re not intentionally supporting RTL languages, please set supportsRtl="false".
If you work at Google or influence Android development tools, please consider changing the default behavior to be opt-in rather than opt-out.
If you’re a user affected by these issues, don’t suffer in silence. Report bugs to app developers. Many don’t even know these problems exist. At least some of them will fix them.
Technology should work for everyone, regardless of which language they speak or which direction their language is written. This bug represents a small but important way that our interconnected world still fails to accommodate its own diversity.
The fix is simple. The impact would be enormous. All it takes is the will to change one line of code—and one default setting—at a time.
¹ Notably, the NJ Transit and the New York MTA’s TrainTime apps still have this bug, even though I’m quite sure that I reported it to them. In the battle of the state transportation agencies for not giving broken apps to people who use their phones in RTL languages, Massachusetts’ MBTA wins big time for now!
Well over 200 languages are spoken in the African country of Cameroon. Two of them are French and English, which are official because colonialism. Many people in Cameroon know them, but definitely not everyone. Two other big languages are spoken in Cameroon and in many other countries: Fula and Arabic.
All the other languages spoken in Cameroon, however, are unique to that country. And in none of them there is an edition of Wikipedia. There are very successful editions of Wikipedia in English, French, and Arabic, and there is also a (much) smaller one in Fula, but not everyone in Cameroon knows these big languages, so if you speak one of them, and you don’t know English, French, Arabic, or Fula, and you want to read Wikipedia, well, tough luck.
Unless, that is, you want to write it yourself, in which case I’m here to help as much as I can.
There are other countries in Africa in which there are many languages, but there is some Wikipedia activity in some of them. In Ghana, there’s pretty good activity in Twi, Fante, Dagbani, Moore, and some other languages. In Nigeria, there’s pretty good activity in Hausa, Yoruba, Igbo, Fula, Tyap, and others. In Mozambique, there’s a serious attempt to start a Wikipedia in Makhuwa.
A dance competition in the city of Douala. African women dressed in matching black, red, and yellow outfits dancing on sand. Near them, men in costumes dancing and playing drums. Photo by Johnkekam from Wikimedia Commons, CC-BY-SA 4.0.
At the Wikimania conference, which took place in August 2024 in Katowice, Poland, I met Minette, a woman from Cameroon. As I usually do with people from all countries, I asked her which languages she speaks other than English, and since she was from Cameroon, I was especially excited. “Ngiemboon”, she answered. I had never heard about it before that, but that’s never a problem. I asked if she would be willing to try to start an edition of Wikipedia in her language, and she agreed, because why not.
So I added Ngiemboon as one of the languages that translatewiki supports. She started contributing translations of MediaWiki user interface strings in it, and then she told me that there’s another language in which she thinks there should be an edition of Wikipedia: Duala (also spelled Douala), the main local language of the city of the same name, which is the country’s largest city and economic capital. It’s not her own language, she said, but it’s one of the country’s most important languages, which many people learn as a second language, and she knows a few people who speak it and would be interested in helping the effort.
Besides, she loves songs in it. And isn’t that, like, one of the best reasons to want to help start a Wikipedia in a language?
So I configured Duala for translatewiki, too. And what do you know—her friends actually came in, contributed a lot of translations on translatewiki, and Duala became the first language of Cameroon to cross the threshold for inclusion in MediaWiki as a user interface language!
This is just the first achievement. The real road is still ahead: To create a full-fledged Wikipedia in their language, they need to start writing articles. They haven’t written any yet, but I am sure that with the energy they have, they can do it.
It doesn’t matter what is your native language—it has value, it can be written, it can be used on computers, and can be a way to share your knowledge. Wikipedia doesn’t have to be written in a “big” language like English, French, or Russian. There can be a Wikipedia in your language, and if you want to invest some effort in writing it, I’ll do all I can to help you do it.
I sometimes see a bad mistake in a Hebrew translation of a message in MediaWiki, the software that runs Wikipedia. I check who made it, and see that it’s myself, a few years ago.
I post something like this on social networks every few weeks, but this time it’s special.
Here’s the timeline of a silly bug that took way, way too long to fix, and it’s 100% my fault:
March 21, 2017, morning: I translate the message mobile-frontend-joined-years, which says “Joined X years go” next to the username on the mobile site. The message takes two parameters: $1 and $2. $1 is the gender of the user, so that it will be possible to write the verb “joined” in the correct grammatical gender. It’s irrelevant for English, but relevant for many languages. $2 is the number of years, so that it will be possible to write “year” or “years” correctly in “1 year”, “2 years”, “4 years”, etc. With Hebrew, the plural forms of years are a tad more complicated than in English: for the specific case of two years, a different plural ending is used: “3 shaním”, “7 shaním”, etc., but when it’s two, the word is “shnatáyim” (and the number is not written at all, because the ending already means that it’s 2). The way to do it in translations is to use the {{PLURAL}} syntax. In English, it looks like {{PLURAL:$2|$2 year|$2 years}}. In Hebrew (in transliteration into Latin letters), it would have to look like this: {{PLURAL:$2|shaná|shnatáyim|$2 shaná|$2 shaním}} (the first form is for 1 year, the second is for 2 years, the third is for some special cases where the singular ending is used even though the number is not 1, and the last form is for all other numbers).
March 21, 2017, midday: A few hours later, I notice that I made a mistake and used $1 everywhere instead of using $1 for gender and $2 for plural. The likely reason I noticed it at that time is that I checked what things have to be translated. Since I’ve tried to keep the translation into Hebrew at 100% most of the time since 2010, there are usually few of those. Even though I had translated it already a few hours earlier, this thing showed up because our translation auto-validation system noticed that the $2 parameter is missing from the translation, and messages with mistakes are shown together with messages that are not yet translated. And here’s where I made another mistake: I fixed the appearance of $1 to $2 within the “PLURAL” values, but I left it as $1 in the beginning. As a result, the algorithm was trying to determine the plural form based on the gender, which obviously cannot work.
And because now both $1 and $2 were used in the translation, our translation auto-validation system stopped noticing it as a mistake. I’m not blaming the system or the people who developed it. Auto-validation systems are built for catching the most obvious bugs. In theory, it can be improved to catch this bug, but it would require some work, and it’s probably not the most important thing to fix.
August 28, 2017: It came to my attention that “Joined 2 years ago” appears in Hebrew as “2 shaním” and not as “shnatáyim”. I checked the translation, but didn’t notice that it says “$2” instead of “$1”. Instead, I reported a bug. Two developers tried to look at it and help, but didn’t come to any conclusions.
July 23, 2020: A developer of the mobile web interface, who was probably going through old and forgotten bug reports, wondered whether this is still a bug. I said that it is.
July 24, 2020: The same developer noticed that the translation says PLURAL:$1 instead of PLURAL:$2 and wrote a comment in the bug report. I didn’t notice it, even though I reported the bug. I guess I can use “the summer of 2020 was all weird COVID days!!” as an excuse.
July 25, 2024: An anonymous Hebrew Wikipedia user noticed that issue again. I started investigating it, came upon my own old bug report, and finally noticed the correctly-identified problem in the translation.
Immediately after that, I fixed the translation.
Over those seven years, I had several opportunities to fix this bug, and I didn’t do it. Now, I finally did.
And you know, this is horribly embarrassing, but I am really happy that this Hebrew Wikipedia user reported this bug today. And I wonder why doesn’t this happen much more often and in many more languages. There are definitely more bugs like this—some of them are in Hebrew, and I just haven’t noticed them yet, and many of them are in other languages. For example, when I was fixing this bug in Hebrew, I noticed that the translation of the same message into Belarusian had the same problem, and fixed it. Every now and then, I sporadically notice bugs of this kind in all kinds of languages, and I fix them when it doesn’t require actually knowing the language. Why doesn’t it bother people more often that some things are incompletely or incorrectly translated?
It sometimes happens in people’s lives that someone tells them something that sounds true and obvious at the time. It turns out that it actually is objectively true, and it is also obvious, or at least sensible, to the person who hears it, but it’s not obvious to other people. But it was obvious to them, so they think that it is obvious to everyone else, even though it isn’t.
It happens to everyone, and we are probably all bad at consistently noticing it, remembering it, and reflecting on it.
This post is an attempt to reflect on one such occurrence in my life; there were many others.
(Comment: This whole post is just my opinion. It doesn’t represent anyone else. In particular, it doesn’t represent other translatewiki.net administrators, MediaWiki developers or localizers, Wikipedia editors, or the Wikimedia Foundation.)
There’s the translatewiki.net website, where the user interface of MediaWiki, the software that powers Wikipedia, as well as of some other Free Software projects, is translated to many languages. This kind of translation is also called “localization”. I mentioned it several times on this blog, most importantly at Amir Aharoni’s Quasi-Pro Tips for Translating the Software That Powers Wikipedia, 2020 Edition.
Siebrand Mazeland used to be the community manager for that website. Now he’s less active there, and, although it’s a bit weird to say it, and it’s not really official, these days I kind of act like one of its community managers.
In 2010 or so, Siebrand heard something about a bug in the support of Wikipedia for a certain language. I don’t remember which language it was or what the bug was. Maybe I myself reported something in the display of Hebrew user interface strings, or maybe it was somebody else complaining about something in another language. But I do remember what happened next. Siebrand examined the bug and, with his typical candor, said: “The fix is to complete the localization”.
What he meant is that one of the causes of that bug, and perhaps the only cause, was that the volunteers who were translating the user interface into that language didn’t translate all the strings for that feature (strings are also known as “messages” in MediaWiki developers’ and localizers’ jargon). So instead of rushing to complain about a bug, they should have completed the localization first.
To generalize it, the functionality of all software depends, among many other things, on the completeness of user interface strings. They are essentially a part of the algorithm. They are more presentation than logic, but the end user doesn’t care about those minor distinctions—the end user wants to get their job done.
Those strings are usually written in one language—often English, but occasionally Japanese, Russian, French, or another one. In some software products, they may be translated into other languages. If the translation is incomplete, then the product may work incorrectly in some ways. On the simplest level, users who want to use that product in one language will see the user interface strings in another language that they possibly can’t read. However, it may go beyond that: writing systems for some languages require special fonts, applying which to letters from another writing system may cause weird appearance; strings that are supposed to be shown from left to right will be shown from right to left or vice versa; text size that is good for one language can be wrong for another; and so forth.
In many cases, simply completing the translation may quietly fix all those bugs. Now, there are reasons why the translation is incomplete: it may be hard to find people who know both English and this language well; the potential translator is a volunteer who is busy with other stuff; the language lacks necessary technical terminology to make the translations, and while this is not a blocker —new terms can be coined along the way—, this may slow things down; a potential translator has good will and wants to volunteer their time, but hasn’t had a chance to use the product and doesn’t understand the messages’ context well enough to make a translation; etc. But in theory, if there is a volunteer who has relevant knowledge and time, then completing the translation, by itself, fixes a lot of bugs.
Of course, it may also happen that the software actually has other bugs that completing the localization won’t fix, but that’s not the kind of bugs I’m talking about in this post. Or, going even further, software developers can go the extra mile and try to make their product work well even if the localization is incomplete. While this is usually commendable, it’s still better for the localizers to complete the localization. After all, it should be done anyway.
That’s one of the main things that motivate me to maintain the localization of MediaWiki and its extensions into Hebrew at 100%. From the perspective of the end users who speak Hebrew, they get a complete user experience in their language. And from my perspective, if there’s a bug in how something works in Wikipedia in Hebrew, then at least I can be sure that the reason for it is not that the translation is incomplete.
As one of the administrators of translatewiki, I try my best to make complete localization in all languages not just possible, but easy.¹ It directly flows out of Wikimedia’s famous vision statement:
Imagine a world in which every single human being can freely share in the sum of all knowledge. That’s our commitment.
I love this vision, and I take the words “Every single human being” and “all knowledge” seriously; they implicitly mean “all languages”, not just for the content, but also for the user interface of the software that people use to read and write this content.
If you speak Hindi, for example, and you need to search for something in the Hindi Wikipedia, but the search form works only in English, and you don’t know English, finding what you need will be somewhere between hard and impossible, even if the content is actually written in Hindi somewhere. (Comment #1: If you think that everyone who knows Hindi and uses computers also knows English, you are wrong. Comment #2: Hindi is just one example; the same applies to all languages.)
Granted, it’s not always actually easy to complete the localization. A few paragraphs above, I gave several general examples of why it can be hard in practice. In the particular case of translatewiki.net, there are several additional, specific reasons. For example, translatewiki.net was never properly adapted to mobile screens, and it’s increasingly a big problem. There are other examples, and all of them are, in essence, bugs. I can’t promise to fix them tomorrow, but I acknowledge them, and I hope that some day we’ll find the resources to fix them.
Many years have passed since I heard Siebrand Mazeland saying that the fix is to complete the localization. Soon after I heard it, I started dedicating at least a few minutes every day to living by that principle, but only today I bothered to reflect on it and write this post. The reason I did it today is surprising: I tried to do something about my American health insurance (just a check-up, I’m well, thanks). I logged in to my dental insurance company’s website, and… OMFG:
What you can see here is that some things are in Hebrew, and some aren’t. If you don’t understand the Hebrew parts, that’s OK, because you aren’t supposed to: they are for Hebrew speakers. But you should note that some parts are in English, and they are all supposed to be in Hebrew.
For example, you can see that the exclamation point is at the wrong end of “Welcome, Amir!“. The comma is placed unusually, too. That’s because they oriented the direction of the page from right to left for Hebrew, but didn’t translate the word “Welcome” in the user interface.² If they did translate it, the bug wouldn’t be there: it would correctly appear as “ברוך בואך, Amir!“, and no fixes in the code would be necessary.
You can also see a wrong exclamation point in the end of “Thanks for being a Guardian member!“.
There are also less obvious bugs here. You can also see that in the word “WIKIMEDIA” under the “Group ID” dropdown, the letter “W” is only partly seen. That’s also a typical RTL bug: the menu may be too narrow for a long string, so the string can be visually truncated, but it should happen at the end of the string and not in the beginning. Because the software here thinks that the end is on the left, the beginning gets truncated instead. This is not exactly an issue that can be fixed just by completing the localization, but if the localization were complete, it would be easier to notice it.
There are even more issues that you don’t notice if you don’t know Hebrew. For example, there’s a button with a weird label at the top right. Most Hebrew speakers will understand that label as “a famous website”, which is probably not what it is supposed to say. It’s more likely that it’s supposed to say “published web page”, and the translator made a mistake. Completing the translation correctly would fix this mistake: a thorough translator would review their work, check all the usages of the relevant words, and likely come up with a correct translation. (And maybe the translation is not even made by a human but by machine translation software, in which case it’s the product manager’s mistake. Software should never, ever be released with user interface strings that were machine-translated and not checked by a human.)
Judging by the logo at the top, the dental insurance company used an off-the-shelf IBM product for managing clients’ info. If I ask IBM or the insurance company nicely, will they let me complete the localization of this product, fixing the existing translation mistakes, and filing the rest of the bugs in their bug tracking software, all without asking for anything in return? Maybe I’ll actually try to do it, but I strongly suspect that they will reject this proposal and think that I’m very weird. In case you wonder, I actually tried doing it with some companies, and that’s what happened most of the time.
And this attitude is a bug. It’s not a bug in code, but it is very much a problem in product management and attitude toward business.
If you want to tell me “Amir, why don’t you just switch to English and save yourself the hassle”, then I have two answers for you.
The first answer is described in detail in a blog post I wrote many years ago: The Software Localization Paradox. Briefly: Sure, I can save myself the hassle, but if I don’t notice it and speak about it, then who will?
The second answer is basically the same, but with more pathos. It’s a quote from Avot 1:14, one of the most famous and cited pieces of Jewish literature outside the Bible: If I am not for myself, who is for me? But if I am for my own self, what am I? And if not now, when? I’m sure that many cultures have proverbs that express similar ideas, but this particular proverb is ours.
And if you want to tell me, “Amir, what is wrong with you? Why does it even cross your mind to want to help not one, but two ultramegarich companies for free?”, then you are quite right, idealistically. But pragmatically, it’s more complicated.
Wikimedia understands the importance of localization and lets volunteers translate everything. So do many other Free Software projects. But experience and observation taught me that for-profit corporations don’t prioritize good support for languages unless regulation forces them to do it or they have exceptionally strong reasons to think that it will be good for their income or marketing.
It did happen a few times that corporations that develop non-Free software let volunteers localize it: Facebook, WhatsApp, and Waze are somewhat famous examples; Twitter used to do it (but stopped long ago); and Microsoft occasionally lets people do such things. Also, Quora reached out to me to review the localization before they launched in Hebrew and even incorporated some of my suggestions.³
Very often, however, corporations don’t want to do this at all, and when they do it, they often don’t do it very well. But people who don’t know English want—and often need!—to use their products. And I never get tired of reminding everyone that most people don’t know English.
So for the sake of most humanity, someone has to make all software, including the non-Free products, better localized, and localizable. Of course, it’s not feasible or sustainable that I alone will do it as a volunteer, even for one language. I barely have time to do it for one language in one product (MediaWiki). But that’s why I am thinking of it: I would be not so much helping a rich corporation here as I would be helping people who don’t know English.
Something has to change in the software development world. It would, of course, be nice if all software became Freely-licensed, but if that doesn’t happen, it would be nice if non-Free software would be more open to accepting localization from volunteers. I don’t know how will this change happen, but it is necessary.
If you bothered to read until here, thank you. I wanted to finish with two things:
To thank Siebrand Mazeland again for doing so much to lay the foundations of the MediaWiki localization and the translatewiki community, and for saying that the fix is to complete the localization. It may have been an off-hand remark at the time, but it turned out that there was much to elaborate on.
To ask you, the reader: If you know any language other than English, please use all apps, websites, and devices in this language as much as you can, bother to report bugs in its localization to that language, and invest some time and effort into volunteering to complete the localization of this software to your language. Localizing the software that runs Wikipedia would be great. Localizing OpenStreetMap is a good idea, too, and it’s done on the same website. Other projects that are good for humanity and that accept volunteer localization are Mozilla, Signal, WordPress, and BeMyEyes. There are many others.⁴ It’s one of the best things that you can do for the people who speak your language and for humanity in general.
¹ And here’s another acknowledgement and reflection: This sentence is based on the first chapter of one of the most classic books about software development in general and about Free Software in particular: Programming Perl by Larry Wall (with Randal L. Schwartz, Tom Christiansen, and Jon Orwant): “Computer languages differ not so much in what they make possible, but in what they make easy”. The same is true for software localization platforms. The sentence about the end user wanting to get their job done is inspired by that book, too.
² I don’t expect them to have my name translated. While it’s quite desirable, it’s understandably difficult, and there are almost no software products that can store people’s names in multiple languages. Facebook kind of tries, but does not totally succeed. Maybe it will work well some day.
³ Unfortunately, as far as I can tell, Quora abandoned the development of the version in Hebrew and in all other non-English languages in 2022, and in 2023, they abandoned the English version, too.
⁴ But please think twice before volunteering to localize blockchain or AI projects. I heard several times about volunteers who invested their time into such things, and I was sad that they wasted their volunteering time on this pointlessness. Almost all blockchain projects are pointless. With AI projects, it’s more complicated: some of them are actually useful, but many are not. So I’m not saying “don’t do it”, but I am saying “think twice”.
I was wondering: In which languages, user interface translations tend to be longer, and in which ones they are shorter?
The intuitive answers to these questions are that Chinese and Japanese are very short, English tends to be shorter than the average, Hebrew is shorter than English, and the longest ones are Turkish, Finnish, German, and Tamil. But what if I try to find a more precise answer?
So I made a super-simplistic calculation: I checked the average length of a core MediaWiki user interface message for English and the 150 languages with the highest number of translations.
I sorted them from the shortest average length to the longest. The table is at the end of the post.
Here’s a verbal summary of some interesting points that I found:
The shortest messages are found, unsurprisingly, in Chinese, Japanese, and Korean.
Another group of languages that surprised me by having very short translations are some Arabic-script languages of South Asia: Saraiki, Punjabi, Sindhi, Pashto, Balochi.
Three more languages surprised me by being at the shorter end of the list: Hill Mari (mhr) and Northern Sami (se), which are Finno-Ugric, a family known for agglutinative grammar that tends to make words longer; and Armenian, about which I, for no particular reason, had the impression that its words are longish.
English is at #22 out of 151, with an average length of 38.
Hebrew is slightly above English at #21, with 37.9. This surprised me: I was always under the impression that Hebrew tends to be much shorter.
The longest languages are not quite the ones I thought! The longest ones tend to be the Romance languages: Lombard, French, Portuguese, Spanish, Galician, Arpitan, Romanian, Catalan.
Three Germanic languages, namely Colognian, German and Dutch, are on the longer end of the list, but not all of them. (Colognian is the longest in my list. The reason for this is not so natural, though: The most prolific translator into it, User:Purodha, liked writing out abbreviations in full, so it made many strings longer than they could be. He passed away in 2016. May he rest in peace.)
Other language groups that tend to be longer are Slavic (Belarusian, Russian, Bulgarian, Polish, Ukrainian) and Austronesian (Sakizaya, Ilokano, Tagalog, Bikol, Indonesian).
Other notable, but not easily grouped languages that tend to be longer are Irish, Greek, Shan, Quechua, Finnish, Hungarian, Basque, and Malayalam. All of them have an average length between 45 and 53 characters.
Turkish is only slightly above average with 44.1, at #88.
Tamil is a bit longer, with an average length of 44.6, at #94. Strings in its sister language Malayalam are considerably longer, 49.1.
The median length is 43, and the average for everyone is 42. Notable languages at these lengths are Mongolian, Serbian, Welsh, Norwegian, Malaysian, Esperanto, Georgian, Balinese, Tatar, Estonian, and Bashkir. (Esperantistoj, ĉu vi ĝojas aŭdi, ke via lingvo aperas preskaŭ ĝuste en la mezo de ĉi tiu listo?)
One important factor that I didn’t take into account is that, for various reasons, translators to different languages may select to translate different messages, and one of those reasons may be that people choose to translate shorter messages first because they are usually easier. I addressed this in a very quick and dirty way, by ignoring strings longer than 300 characters. Some time in the (hopefully near) future, I’ll try to make a smarter way to calculate it.
And here are the full results. Please don’t take them too seriously, and feel free to write your own, better, calculation code!
#
Language code
Average translation length
1
zh-hans
17.67324825
2
zh-hant
18.52284388
3
skr-arab
21.81899964
4
ja
24.67007612
5
ko
25.8110372
6
sd
27.71960396
7
mhr
28.95451413
8
ps
32.73647059
9
pnb
33.03592163
10
bgn
34.39934667
11
se
34.69274476
12
hy
35.02317597
13
su
35.37706967
14
th
35.52957892
15
ce
35.6969602
16
mai
36.02093909
17
lv
36.14100906
18
gu
36.59380971
19
bcc
36.64866033
20
fy
37.60139287
21
nqo
37.94138834
22
he
37.95259865
23
en
38.04300371
24
ar
38.18569036
25
ckb
38.66867672
26
min
38.71156958
27
ses
38.87941712
28
jv
38.94753377
29
is
39.0652467
30
alt
39.39977435
31
az
39.4337931
32
kab
39.50967506
33
tk
39.54990758
34
mr
39.72049689
35
as
39.72080166
36
sw
39.73986071
37
km
39.77591036
38
azb
39.92411642
39
nn
39.96771069
40
yo
40.00503291
41
io
40.0528125
42
af
40.1640678
43
blk
40.2813059
44
sco
40.33289474
45
diq
40.33887373
46
yi
40.34033476
47
ur
40.39857651
48
ug-arab
40.53965184
49
da
40.55894826
50
my
40.67551519
51
kk-cyrl
40.87443182
52
guw
41.07080182
53
mg
41.08369028
54
sq
41.23219241
55
fa
41.27007299
56
or
41.27020202
57
ne
41.33971151
58
rue
41.40219378
59
lfn
41.54527278
60
lrc
41.61281337
61
sah
41.63293173
62
vi
41.74578313
63
awa
41.84093291
64
hi
41.9257885
65
si
41.93065693
66
te
41.99780915
67
mn
42.18728223
68
lki
42.21091396
69
bjn
42.57961538
70
sr-ec
42.67730151
71
cy
42.75020408
72
frr
42.92761394
73
vec
43.00573682
74
sr-el
43.13764389
75
nb
43.34987835
76
krc
43.54919554
77
ms
43.5553814
78
hr
43.55564807
79
eo
43.57477789
80
nds-nl
43.59060895
81
ka
43.60108696
82
ban
43.64178033
83
bs
43.681094
84
tt-cyrl
43.78230132
85
xmf
43.80860161
86
et
43.96494239
87
ba
43.99432099
88
tr
44.17996604
89
bn
44.28768449
90
bew
44.44706174
91
sv
44.49027333
92
sa
44.58670931
93
cs
44.59026764
94
ta
44.62803055
95
mt
44.70207417
96
lt
44.7615
97
roa-tara
44.79812466
98
fit
44.79824561
99
dsb
44.9151957
100
hsb
44.96197228
101
br
44.98873461
102
sh-latn
45.00976709
103
fi
45.1222031
104
hu
45.17139303
105
sk
45.35804702
106
lb
45.39073034
107
li
45.5539548
108
id
45.56471159
109
gsw
45.63605209
110
sl
45.75350606
111
be
45.80325
112
oc
45.85709988
113
mk
45.90943939
114
bcl
45.97070064
115
scn
46.11905532
116
an
46.14892665
117
uk
46.22955524
118
qu
46.30301842
119
eu
46.33589404
120
lij
46.660536
121
pl
46.76863316
122
hrx
46.79802761
123
ast
46.87204161
124
nap
46.93783147
125
ru
47.02326139
126
bg
47.03590259
127
be-tarask
47.28525242
128
hif-latn
47.41652614
129
tl
47.51263001
130
rm
47.60741067
131
pms
47.69805527
132
pt-br
47.84063647
133
ca
47.92468307
134
ro
48.22437186
135
nl
48.4175636
136
ia
48.48612816
137
it
48.52347014
138
frp
48.54542755
139
gl
48.57820482
140
ml
49.12108224
141
es
49.21062944
142
pt
49.63085602
143
de
49.77225067
144
szy
49.84650877
145
shn
49.92356241
146
fr
50.15585031
147
lmo
50.85627837
148
ilo
50.9798995
149
el
51.14834894
150
gd
51.72994269
151
ksh
53.36332609
The Python 3 code I’ve used to create the table. You can run in the root directory of the core MediaWiki source tree. It’s horrible, please improve it!
import json
import os
import re
languages = {}
code_re = re.compile(r"(?P<code>[^/]+)\.json$")
def process_file(filename):
code_search = code_re.search(filename)
code = code_search.group("code")
if code in ('qqq', 'ti', 'lzh', 'yue-hant'):
return
with open(filename, "r", encoding="utf-8") as file:
data = json.load(file)
del(data['@metadata'])
average_unicode_length(code, data)
def average_unicode_length(language, translations):
total_translations = len(translations)
if total_translations < 2200:
print('Language ' + language + ' has fewer than 2200 translations')
return
total_length = 0
for translation in translations.values():
if len(translation) < 300:
total_length += len(translation)
# Calculate the average length
average_length = total_length / total_translations
languages[language] = average_length
root = "./languages/i18n/"
for file in os.listdir(root):
if file.endswith(".json"):
path = os.path.join(root, file)
process_file(path)
sorted_languages = sorted(
languages.items(),
key=lambda item: item[1]
)
# Print the sorted items
for code, length in sorted_languages:
print(code, '\t', length)
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.
When we became parents in 2014, my wife searched for a mobile app to help manage baby care: feeding, sleep, diaper changing, and other activities.
After trying a few apps, she settled on Baby Daybook by Drilly Apps. It indeed turned out to be very convenient for parenting in the first few months, but here I wanted to praise its developers for doing localization right:
The app is translatable at OneSky. It’s one of many other localization sites existing today. It’s probably less famous than Crowdin and Transifex, but pretty fine functionally, and I have not particular complaints about it. (And of course, it’s a bit of a competitor of translatewiki.net, where I am one of the maintainers, but that’s OK—competition is healthy.)
Any volunteer can log in with a GitHub account and start translating to any language.
Translation review is available, but not required. Submitted translations go into the next released version whether reviewed or not. This is good, because bad translations are actually very rare, and many languages have very few dedicated translation maintainers, often just one, so demanding translation review is usually just harmful and unnecessary overhead.
The developers quickly answer my emails when I ask them for clarification about string meanings, and when I suggest changes in the English string. Recently I suggested changing “Thousands of happy moms use this app to track breastfeedings and sync data” to “Thousands of happy parents use this app to track breastfeedings and sync data”, and they immediately changed it.
App descriptions for the Google Play store are fully translatable. This may seem like an obvious thing to do, but almost all apps use a machine translation, which is almost always wrong, often embarrassingly so. I saw some very popular apps, used by millions of people, having Hebrew and Russian descriptions that are worse than useless. For a lot of apps it would be better to just leave the English description. Luckily, Baby Daybook does the right thing and allows translators write a complete description for every language.
Translators get a free pro account in the app, with extra features. (This worked for me the last time I checked, in 2014; I haven’t checked recently, but I have no reason to think that it changed.)
All of the above things are really easy and sensible, but for some reason most app developers don’t do this.
App developers, please learn from Drilly Apps how to do it right.
As you probably already know, Wikipedia is a website. A website has content—the articles; and it has user interface—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 of the user interface translated to your language, as quickly 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 3,335 messages to translate in MediaWiki, and the number grows frequently. “Messages” in the MediaWiki jargon are strings that are shown in the user interface, and that can be translated. In addition to core MediaWiki, Wikipedia also has dozens of MediaWiki extensions installed, some of them very important—extensions for displaying citations and mathematical formulas, uploading files, receiving notifications, mobile browsing, different editing environments, etc. There are around 3,500 messages to translate in the main extensions, and over 10,000 messages to translate if you want to have all the extensions translated. 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 enormous job, and yes, it takes time, but it’s doable.
In February 2011 or so—sorry, I don’t remember the exact date—I completed the translation into Hebrew of all of the messages that are needed for Wikipedia and projects related to it. 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, and if you were a Hebrew speaker, you didn’t need to know a single English word to use it.
I wasn’t the only one who did this 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, Inkbug (whose real name I don’t know), 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.
Of course, 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 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 I am ill. It slipped for quite a few months because in late 2014 I became a father, and a lot of new messages happened to be added at the same time, but Hebrew is back at 100% now. And I keep doing this.
With the sincere hope that this will be useful for translating the software behind Wikipedia to your language, let me tell you how.
Preparation
First, let’s do some work to set you up.
Get a translatewiki.net account if you haven’t already.
Make sure you know your language code.
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 the former Soviet Union like Tatar (tt) or Azerbaijani (az), then you probably also know Russian (ru). 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
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 in 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 different 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 of 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 15,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).
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 strike 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, sorted not by importance, but by the number of messages to translate:
Cite: the extension that displays footnotes on Wikipedia
Babel: the extension that displays boxes on userpages with information about the languages that the user knows
Math: the extension that displays math formulas in articles
Thanks: the extension for sending “thank you” messages to other editors
Universal Language Selector: the extension that lets people 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
Wikibase Client: the part of Wikidata that appears on Wikipedia, mostly for handling interlanguage links
VisualEditor: the extension that allows Wikipedia articles to be edited in a WYSIWYG style
ProofreadPage: the extension that makes it easy to digitize PDF and DjVu files on Wikisource
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 to be honest, 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 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”, 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. (Going to all extensions, beyond Extensions used by Wikimedia, helps users of these extensions, but doesn’t help Wikipedia very much.) This strategy can work well if you have several people translating to your language, because it’s easy to divide work by topic.
Another 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 Malay. You only need to translate eight messages to go up a notch (901 – 894 + 1). Then six messages more to go up another notch (894 – 888). And so on.
Once you’re done, you will have translated over 3,400 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 over 10,000 messages, but the same strategies work.
Good Stuff to Do Along the Way
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. They may know their code very well, but they may not be the most brilliant 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. 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, and English is foreign to them, and they may make mistakes.
So report problems with the English messages to the translatewiki Support page. (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 running 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 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, 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 how important it is to do this every day.
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 is just a small number of new messages to translate; I didn’t measure precisely, but usually it’s less 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? 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”.
Oh, and enormous experience with software localization, which is a rather useful 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.
Versions of this post were already published in the following languages:
In the last few years, I usually have some files of Israeli music with me when I leave my home, or my country – on my laptop or on my phone (ripped from CDs that I own, which is legit as far as my interpretation of copyright law goes).
And sometimes people from other countries are curious about it and ask me to copy some files for them. This is a copyright issue, but I justify it by the fact that they hardly have a chance to purchase it where they live, so they aren’t really hurting the relevant market. But there’s something bigger: a technical issue with the artist and song names.
Hebrew is written in the Hebrew alphabet. CDs have artist names and song titles in Hebrew, with English translations or transliterations added only occasionally. When I rip CDs, I give the files names in Hebrew letters. Most people around the world don’t know the Hebrew alphabet, so looking for a song they like using these files will be impossible for them. They would only be able to enjoy them if they don’t mind listening to everything in a shuffle. And though the newest phones are able to display Hebrew correctly, some devices that people have are still unable to do that.
I actually recall myself renaming files en masse to let friends from other countries listen to some Israeli music and now the artists’ names.
I’m not sure how to resolve this robustly, but much like with email and social networks and with legal forms, songs could use titles in different languages or scripts. Maybe MusicBrainz or Wikidata could add a structured property for transliterated song titles, and music files could be identified like that. Maybe each music track could have multiple fields for titles in different languages.
It’s good not just for international exchange between friends, but for marketing, too – some cultures only listen to music in English and maybe in their own language, but some are OK with listening to music in a lot of languages, because they are all equally foreign.
Long story short, song names must be more easily localizable than they are today.
Aharoni in Unicode 
