Why Esperanto and Syriac? About the New Multilingual Word Processor

Interview with Ori Redler, Co-founder, RedleX
(Interviewed by Arle Lommel, LISA Publications Manager)

RedleX, a privately-owned Tel Aviv-based software development company, released Mellel, its multilingual word processor for Mac OS X in May 2002. While the release of Mac OS X in 2000 offered the framework for multilingual and multi-script support, few applications have implemented anything but basic Unicode support. With support for a wide variety of scripts, including some supported in no other applications, and eighteen localized versions (with all localizations provided through volunteer efforts), Mellel is a product clearly aimed at the “global” marketplace. The company’s secret is a localization framework that allows them to spend roughly the same amount of effort for eighteen localized versions, as for thirty. Retailing for just US$ 39, it is also affordable in much of the world. In this interview, Ori Redler, co-founder of the company, talks about the history of Mellel and why RedleX has invested so much in support for minority languages.

Ori Redler, Co-founder, RedleX INSIDER: How did you get involved in developing “the most advanced, multilingual word processor for Macintosh OS X”?

My brother and I, the original founders of RedleX, began creating applications and utilities for the Macintosh in 1997. Most of those applications were hobby projects. Others were commissioned work. We had some fleeting thoughts about writing something that would be more “serious” or “major” but, to be honest, did not realistically believe that our limited resources would ever suffice to allow us to do that.

Then along came Mac OS X and changed our thinking. Mac OS X, for us, had three very important advantages. First, Mac OS X was a new thing. Most of the applications for the Macintosh did not have Mac OS X-compatible versions and most of those that did were rather dingy. This meant that we could hope for a chance to battle the “ancient-régime” applications on even ground, instead of engaging in an uphill battle against applications deeply entrenched in people’s hearts and pockets. Second, Apple offered developers a free and very innovative development environment that made it relatively fast and easy for a small group of developers to bring a good product to market. Third, we had our day job doing something else, so we thought, what the heck, we’ll develop this as yet another hobby project. Thus, Mellel was born.

Every new version doubled or tripled its predecessor in terms of downloads, user response and sales.

Once we got into the fray, however, our thoughts about the project changed. Although we kept working on Mellel as a hobby project, the response from people who used it was simply overwhelming. Every new version doubled or tripled its predecessor in terms of downloads, user response and, as we became a for-fee product, in terms of sales.

With everything going so well, we also started developing in terms of our ambitions. As a professional writer, I have worked with word processors for almost twenty years, and I have, so to speak, developed “a taste” for the matter. I had a “dream word processor” in mind. Now, it seemed, we had, for the first time, a realistic chance to build such a dream machine for our needs and for the needs of other users.

INSIDER: Mellel currently is localized into eighteen languages: Czech, Danish, Dutch, English, Esperanto, French, German, Greek, Hebrew, Italian, Japanese, Norwegian, Polish, Romanian, Russian, Serbian, Spanish and Swedish, with Welsh and Persian (Farsi) on the way. All of this in an application that retails for US$ 39. How have you been able to provide a level of localization support that many products costing hundreds of dollars have been unable to achieve?

I think that the main keyword is respect. Some people from English-speaking nations, particularly the U.S., have this pat fantasy that people around the world want to adopt the English language as their native language. They don’t. People want to use their own language and would invariably prefer it to any other, where possible. Being non-native speakers of English ourselves, we have experienced the bitter taste of having to use a product that is not localized for our language, so this might have improved our understanding of the situation. But the bottom line is that it is mainly a question of basic respect for others.

Some people from English-speaking nations have the fantasy that people around the world want to adopt English as their native language.

Do other developers show disrespect by not issuing localized versions of their products? Not necessarily. Many of them, I feel, simply lack the awareness or tend to ignore markets outside English-speaking countries as “irrelevant.” I can understand the financial sense of this decision, at least with respect for some languages. But I think this is also a misunderstanding of the situation. The fact that Czech, Greek or Swedish users don’t make a fuss about getting their localized versions doesn’t mean that they don’t need them. They do. They’re just being civil about it, or, worse, are simply accustomed to being ignored.

INSIDER: Do you have a priority for choosing languages? While the motivation to localize into German or Japanese is fairly obvious, what about Esperanto? There can’t be a huge demand for an Esperanto localization.

We don’t give any priority to this or that language. Our thinking is that even if a localization serves a small number of people, their needs still deserve our respect and the minimal amount of effort needed to create a localized version. The last is key here: we’ve constructed our localization framework so that we can localize all the languages together, with a minimal amount of problems and time per language. This way, having eighteen localizations or thirty localizations would mean roughly the same amount of effort on our part.

INSIDER: Since you rely on volunteer efforts for localization, how do you locate and manage localizers. How do you verify translation quality prior to release?

We try to keep our localization efforts as “RedleX-free” as possible. We cannot review the contents of localizations ourselves, nor can we afford to hire experts to review them all. However, we wouldn’t want to even if we could: it would be both costly and ineffective. Instead, we give our volunteer localizers the freedom to create the localization as they see fit and let the “market” correct any errors they make. In other words, if some string is not translated properly, either the localizer or other users will come up and correct the errors made.

So far, this approach has proved to work very well. For about two-thirds of our localizations, we have received only a very small number of corrections, most of which came from the localizers themselves. In some cases, people have volunteered to serve as reviewers for localizations, and this has worked exceptionally well.

INSIDER: What motivates people to provide you with localizations? Large companies would have to spend a considerable amount to achieve the locale support you have, but you are getting this essentially at zero cost.

Although we do not pay our localizers, we have done several things to make their localization efforts easier. To start with, we have constructed the localization process so that a fast localizer can accomplish the initial localization in a matter of a few hours. Beyond that, we try to make sure that they do not have to invest more than thirty minutes or so every three to four months to update the localization to the most current version.

Large companies suffer because they’re impersonal; testers and localizers do not feel they have any voice in matters of features, options or localization, or how these are implemented.

In addition to that, there’s also the community aspect. Mellel is a product that is near and dear to many, and for some, it merits the effort needed to localize it. This is similar, I think, to the way our beta testing process works. We have around 300 beta testers for Mellel. They don’t get paid for doing beta testing—they enjoy it because it’s a chance to make a difference and to influence the future of a product that, at the bottom line, is built to serve their needs.

Large companies, I think, suffer because they’re impersonal; testers and localizers do not feel they have any voice in matters of features, options or localization, or how these are implemented. When you listen to people and care about what they say, they’ll respond in kind. When you don’t, and this is the situation with many larger companies, why should users react otherwise?

INSIDER: Mellel 1.8 offers an impressive list of typographical features that rival or even exceed the capabilities of applications from major developers like Microsoft and Adobe. In some cases, you have even beat the big players to the market with support for OpenType features that they themselves developed. For example, Microsoft Office 2004 for Macintosh OS X just introduced basic Unicode support earlier this year, but as yet, provides no support for OpenType script features or anything but left-to-right scripts. What is your motivation for providing support for these features, and how do you achieve it absent any previous implementations on the Mac to guide your programming efforts?

Simply entering non-Roman characters is not OpenType support, and it’s not very useful.

TextEdit (the basic text processor bundled with Mac OS X), and practically any other application, has always supported OpenType fonts to the extent that they have allowed users to enter regular text using those fonts (they are, after all, TrueType or PostScript fonts at heart). In some cases, users were able to enter non-Roman characters using the Character palette. This, however, is not OpenType support, and it’s not very useful.

The real power of OpenType is that it allows real-time repositioning and reordering of characters. For example, if you have the Hebrew character Aleph, and you add a vowel marking, an application with OpenType support knows how to position the vowel mark correctly, centered under the Aleph. When you enter this through a palette, as in Microsoft Office, you don’t have an Aleph+Vowel mark character, because the combination does not exist in the font, but is supposed to be created while you write. While this capability may not matter for the Roman and Cyrillic scripts, it is essential for many non-Roman scripts.

Let’s take an example from Hebrew to show why this support is critical. I’m going to use text from the Bible as some of these needs are most graphically illustrated in religious texts that often have special linguistic requirements. For real support of Hebrew by a word processor, here are the four requirements:

directionality (running from right to left, but also working correctly when mixing Hebrew and Roman text)
justification (block justification)
correct positioning of vowel marks
for full support, diacritic positioning (Trope marks positioning for rendering Biblical texts)

Mellel shows all four and adds some nice gadgets (like the widened letters, which suits an old manuscript):

One of Mellel’s competitors fails in all four: no proper directionality, no proper justification (the last line is not aligned correctly), no correct positioning of vowel marks and of course, no support for Trope positioning.

The final example, Apple’s TextEdit, is a bit better, but not really by much. The directionality and justification are missing. Vowel marking is faulty – see the fourth word on the third line, for example: the two dots, called shva, under the first and the third are positioned incorrectly, when compared with the same (third line, second word) in Mellel. Lastly, the Trope marks are all over the place, but never in the right place.

You can see that, without proper OpenType support, output from word processors ranges from bad to worse. It is only when an application implements OpenType features intelligently that you can deliver the language output users expect.

Ultimately, we support special language-related options with Mellel because that’s our job. Mellel is a word processor that should allow people to write in different languages. That means that we should know how to program it to do so. If Apple supplies some language-related options, then fine, but we cannot rely on it to do so or wait until it does. If people need an option, then they should get it. If Apple doesn’t deliver this option, then we should do this on our own.

In some respects, the approach to doing things on your own corresponds to the difference between a child and an adult. As a child (a starting programmer) you tend to rely on your parents (Apple or Microsoft) to do things for you and to know better how things should be done. You suffice yourself by emulating their work and waiting for their hand-outs.

As you mature as a developer, you learn that your parents are just like you—human beings with strengths and weaknesses. You learn not to rely on them for everything. They can’t do everything for you. If you’ve learned architecture, you don’t stand around waiting for mother to come and plan buildings for you. You plan them on your own. Or, in development terms, you don’t wait for Apple, you just go out and do the stuff yourself.

It took us three months to implement OpenType support. One month was spent being frightened. Two were spent doing it.

Surprisingly, when you adopt that way of thinking, things are not as frightening anymore. If you do not think that “if X did not do it, then it can’t be done,” you find out that it can be done, and much more easily than you first thought. To give a relevant example: we’ve decided to implement OpenType support in Mellel to allow us to support languages and language options that Apple does not and probably never will support, like Syriac and advanced layout for Arabic, Persian and Hebrew. We knew that it took Adobe and Microsoft, the creators of the OpenType technology, about five or six years to implement partial support for this.

Unicode support alone is not enough: OpenType support is critical in ways that users of Roman script software don’t immediately understand.

This track record seemed intimidating, but we thought, “Why not take a look first? If it takes us five years to implement, than we’re not going to do this anyhow, but what if we can implement just a small portion in a reasonable time? No harm in having a short peep.” We peeped and saw that this OpenType monster isn’t nearly as terrible as it sounded at first. So we implemented these features. It took us three months to implement OpenType support. One month was spent being frightened. Two were spent doing it. The four and a half years we “saved” weren’t due to the fact that we’re such excellent and wonderful programmers (although I think we are…) but rather to the fact that we stopped being scared.

The results? Let’s look at an example from Arabic. If you say you have decent support for Arabic, you really need to support these four features of the language:

Right-to-left directionality control
justification (Keshida)
proper selection of contextual forms of characters
required ligatures (to make the text look nice and smooth)

This image from Mellel shows how the first few verses of the Bible should look in Arabic (although I overdid the special ligatures a bit, just to make the point):

The second image, from a competitor’s product, uses the OS support for Arabic, and lacks directionality, contextuality and ligatures. It’s completely useless:

The third image, from Apple’s TextEdit, does much better, but still has problems. It has some directionality (although the direction of the text is not saved with the file) and contextuality, but weak support for ligatures. Note, for example, the first and fourth word from the right (fi ‘in’ and Alla ‘God’): the ligatures are not the ones a person writing in Arabic would expect to get:

Without proper support for the four factors listed above, you end up with text in Arabic that ranges from readable (but clumsy) to absolute garbage. This is why Unicode support alone is not enough, and why OpenType support is critical in ways that users of Roman script software don’t immediately understand.

INSIDER: What feature of Mellel are you the most proud of? What feature was the most difficult to develop?

To air an old cliché, the feature we’re most proud of is the one we’re working on right now. Based on those features already in Mellel, though, I’m particularly proud of two: our footnote/endnote system and our auto-numbers. Our notes system was way ahead of the field when we first introduced it early in 2003. The option to create as many “streams” of notes as you like was truly an innovation in its day. I was quite sure that this option, giving users such clear advantage, would be emulated by many other word processors by now. To my surprise, we’re still just as far ahead of the field in this respect as we were two years ago. Same with auto-numbers, which is even more innovative and in the future will allow us to do some pretty amazing stuff, just like our Outline feature with Mellel 1.8.

RTF suffers from several debilitating diseases. It is clunky, old, inconsistent, messy and a bit of a moron.

The feature that was the most difficult to develop was, without a doubt, export and import of RTF. First, it’s difficult to cater (export, import) for a format that you did not create, because this involves thinking the way another person thinks. In addition, it turned out that this person, RTF, suffers from several debilitating diseases. The format is clunky, old, inconsistent and messy. In short, we not only had to think like someone else, it also turned out that this someone is a bit of a moron.

INSIDER: Some of the features you have implemented, like support for Syriac, are unlikely to repay their development costs given the small market for products based on them. What is your motivation for implementing features that are clearly of benefit to only a small minority of users?

I believe that features developed for a smaller market almost always pay for the development cost in the end. If you build it, they will come. You just have to be patient. In terms of our “policy” view, our market is comprised of many groups of people, large and small, that have many common needs, but also some special needs. We try to provide for all the common needs, but not neglect the special needs of smaller groups.

Features developed for a smaller market almost always pay for the development cost in the end: if you build it, they will come.

In the case of Syriac, for example, most of our users are scholars who have common needs that include notes, numbering and/or table of content creation, but they also need to enter the occasional word or phrase in Syriac. For them, these are make-or-break features. They don’t need Syriac just to be fancy; they need it for work. Before we came up with support for Syriac, if you needed that option, you had to go and buy a Windows machine and forget that you ever owned a Mac. Now, you can simply buy Mellel.

INSIDER: When working with minority languages and “uncommon” scripts, lack of reliable information can be a constraint in development. Where do you find reliable information about the complex features you implement in Mellel?

We usually “discover” the complexities and the special requirements of minority languages as we go along. We read, rely on what we already know, ask people and once we release a new version, we move very quickly to fix problems that are pointed out to us. Taking the Syriac example again, most of the problems there were quite similar to problems we’ve solved when implementing our support for Persian and Arabic, so we could focus very clearly on the differentiating aspects and assume that the mechanisms that we had constructed for Arabic would serve us here as well. For example, Syriac requires proper selection of contextual variants of characters as shown in the two screen shots below, the first from Mellel, and the second from TextEdit. Note, in the underlined portion in TextEdit, that the letters are not properly connected or modified for their place in the word, while Mellel gets them right:

INSIDER: The Digital Divide, the differential access to high technology between peoples and social classes, is a major social concern in the 21st century. Work like Mellel and Gentium (SIL International’s Unicode font that covers a huge assortment of characters) can contribute to a solution to the problem of the Digital Divide. How do you see your work, and the work of other smaller developers as influencing this issue? What can you do that a large company such as Microsoft might not be able to do? How would you recommend LISA members address the issue of the Digital Divide?

This is a serious question, and I feel only semi-optimistic here. Most of our localizations and language support primarily address the needs of people in Europe, the Americas and the Far East (the main exceptions being Persian, Arabic and Hebrew). With the latter group, we probably do make a difference, especially since Mellel is built from the ground up to serve right-to-left languages in addition to left-to-right. Do 3,000 users in Saudi-Arabia, 2,000 in Morocco or 10,000 in Israel make a real difference to the Digital Divide? I’m not sure. It’s certain that we make things easier for users in those countries, but I’m not at all sure if those we help are not already over the Digital Divide to begin with.

We’d rather sell a million copies of Mellel to India for $2 a copy than sell ten for $40 a copy.

From our point of view as software makers—and I think this would apply to all types of makers—the best way we can approach the Digital Divide is by “ignoring” it. That is, we’re selling to countries considered across this Divide not because they’re across it, but because we think Mellel is something they can use and benefit by… and help us pay the bills while we are at it. When making a deal with a dealer in an “across” country, or with a student or school, we lower the price significantly. We’re not doing this as a “favor” to anyone; we do it because it makes good business sense. We’d rather sell a million copies of Mellel to India for $2 a copy than sell ten for $40 a copy. This, I think, is the most practical way to treat this divide and other “divides.”

Ori Redler is co-founder of RedleX. Currently forty years old, he was born and raised in Israel. He has worked as a magazine editor, book editor, journalist, and font and graphic designer. Redler is now half-way through his “big” novel, on which he comments, “It’s gonna be a huge thing, I think.”

Reprinted by permission from the Globalization Insider,
10 December 2004, Volume XIII, Issue 4.2.
Copyright the Localization Industry Standards Association
(Globalization Insider: www.localization.org, LISA: www.lisa.org)
and S.M.P. Marketing Sarl (SMP) 2004