Few of the world's older languages are written from Right-to-Left, as opposed to Latin Left-to-Right. Such languages include Hebrew and Arabic. Writing in the opposite direction than the rest of the world turns to be a bit problematic.
Writing
If you belong to the
right-handed majority of the population, you are more likely to
smear the ink while writing right-to-left, since your fist will be hovering over the text you've written already and resting your fist on the paper while writing will have futile results (unless the ink gets absorbed immediately). Some will claim
Right-to-Left scripts are the
left-handed conspiracy.
Also, at least as it is with Hebrew, you'll need to reserve some space in front of the numbers you're going to write, since the numbers (the Arabic Numberals we all use) go left-to-right. Inserting left-to-right (e.g. English) words and phrases into the text demands you to reserve space too.
Computing
Computer application support of bidirectional languages requires much more effort than usual languages with unique alphabets. With regular languages, you'll simply make up a new 8-bit
character set (e.g.
KOI8-R,
ISO-8859-5 and
CP-1251 for
Cyrillic), map your keyboard and all your
legacy applications are set. Bidirectional languages require you to display the text with reversed strings, going through a special
BiDi algorithm, create special input widgets etc. Simply "reversing it all" isn't acceptable, since we have "mixed" sentences, with numbers and occasional English (or any other left-to-right script) names and phrases.
Hebrew support on modern systems is achieved with support on the widget ("control" in Microsoft-speak) level (e.g. in Hebrew-enabled Microsoft Windows and Apple's Hebrew support), modifying the text printing routines and the input widgets. This will provide Hebrew support in simple applications "transparently". Further work is usually required to make a complex application support Hebrew (e.g. a web browser, a word processor).
Bidirectional text can be stored either:
"Visual" is the old way, which required no Hebrew support at all on legacy viewer applications (text viewers, browsers), while Logical is known as the right way (according to
Microsoft and The
Unicode Consortium). The
Unicode Standard Annex #9 defines the BiDi algorithm which should be used to convert Logical strings into their visual form (typically to be rendered on the screen, on paper etc.). Complete description of the issues involved in BiDi (run direction, overrides etc.) are out of the scope of this node.
In the 1960s, some Israeli doctor had proposed a system called "The Karmelitic Script", which offered to transliterate Hebrew in English, left-to-right, and put an end to the madness, but it never caught on. In 1985, Apple introduced integrated Hebrew support (on the widget level), and so has Microsoft Israel (at least since Windows 3.0). X toolkits are very slow catching up on this field (there were Hebrew-supporting Motif versions for years, but toolkits such as Qt and Gtk only begun supporting Hebrew around 2001). This is one of the blocks on the entrace of free desktops into Israel and Arabic-speaking countries.
Arabic also has the further complexity of being a rather beautiful script, where different letters are connected to one another (ligatures), and their shapes vary depending on their location in the word (first letter, middle letter, final letter). When typing, after you type-in a letter, the letter before it will change from its "final" form to the interconnected form. That's an issue to be taken care of by the text rendering engine.