This is a guide for software writers who want to achieve the three “multis” mentioned in the title. The need for the study on which it is based became clear to the first‐named editor while working on a project in Saudi Arabia, where the user interfaces were in Arabic.
The book stems from a project named Glossasoft, initiated in the Open University and supported by the European Community. Other participants include the Greek National Centre for Scientific Research, and the Finnish Technical Research Centre. There is also participation of the Claris software house, Dublin, and Machines Bull, Paris, and Hewlett Packard Hellas. About 19 people from these various affiliations have contributed to the book, but thorough editing has ensured that the style is uniform throughout.
An obvious first hurdle is the need to accommodate different alphabets, of which the Cyrillic and Greek are the main non‐Latin forms in use within Europe. Also, of course, the Latin alphabet is modified in various ways to suit different languages, with the addition of umlauts, cedillas, accents, and so on. All of these alphabets have a total number of letters not greatly exceeding the 26 of the Latin one, and there are similar conventions about upper and lower cases. For digital representation in any one alphabet a byte of eight binary digits can store a character.
If non‐European languages are to be included the range of possibilities is considerably widened, and Chinese‐style ideograms require two bytes per character. On a keyboard with a reasonable number of keys, two or more keystrokes will be needed for each character and there are problems in arranging this in an intuitive way. Another complication is that, although most languages are written left‐to‐right, some are right‐to‐left and others top‐to‐bottom. Others, notably Arabic, have more than one representation of the same letter, depending on where in the word it occurs.
Apart from the complications these considerations introduce in the processing of text as such there are implications for the interactions of the software with its users. It is possible, for example, that the arrangement of items on a “menu bar”, and the direction of unrolling of pull‐down menus, might not be pleasing to a user whose own first language is not written from left to right. It is also possible that a form of interrogation of the user by the software, acceptable in a particular cultural environment, may seem impolite or non‐idiomatic if translated directly to another.
Since there are obvious commercial advantages in making new software widely available without delay, attention has been given to the presentation of text messages in a form of Interlingua, allowing automatic conversion to respective natural languages. A number of such schemes are reviewed. Difficulties stem from the extreme context‐sensitivity of natural language.
Some operations on text require sorting of words or phrases into alphabetical order, and there is a surprising diversity of conventions about this, even among languages using versions of the Latin alphabet. In some languages, the altered forms of letters (using umlauts, accents, etc.) are treated as separate letters, following in ordering the unmodified form of the same letter. In others, a modified form is treated as equivalent to its parent letter unless the modification is the only point of difference between two items to be ordered. There are also languages where alphabetical ordering is with the unmodified letters from “a” to “z” coming first, followed by the modified forms.
Processes of word‐wrap, justification and hyphenation are complicated by differences among languages. Even the conventions of separating words by spaces, and of terminating sentences with one of a small set of punctuation marks, are not universal. Separation of words in the non‐spaced language has to depend on a form of syntactic analysis based on known word structure.
Knowledge of the rules of grammar of each language is important in other ways. In Appendix C, characteristics of the most common European languages are listed, and some are described as “synthetic” and others, including English, as “analytical”. The former term refers to languages in which words are commonly formed from one or more word stems and an inflectional suffix, while the latter term refers to those in which such constructions are less common. Most if not all European languages are sufficiently synthetic (in this sense) that taking account of the ways that word stems can be modified is essential in designing a syntax‐checking facility and can allow substantial economy in a spelling‐checker, and can extend the usefulness of a search facility.
The Turkish language is not included in Appendix C, though it qualifies as a European language. In its modern form it uses the Latin alphabet but has the typographically‐awkward feature of distinguishing two forms of the letter “i”, one of them with, and the other without, the dot. This is an extra variation to be added to the use of umlauts, cedillas, tildes, etc.
To put the general principles in a definite context, the requirements for an internationalised word‐processor are discussed. Where different languages and possibly different alphabets are used in one document, such things as hyphenation have to be applied according to different rules, possibly within one paragraph or line of text. The text may include markers to show changes of alphabet and possibly to show changes of language without change of alphabet. However, the use of markers may lead to slow responses for some operations since the system has to back‐track through the text to find the most recent marker. A more satisfactory solution is a character‐set large enough to include two or more distinct alphabets. This is likely to require more than one byte per character. A number of different standards and proposals are mentioned, but this aspect is still in a state of flux.
As acknowledged on page 106, the transmission of messages using various character sets is quite usual on the Internet, but it seems to be done without much standardisation. I had hoped to get an indication of what should be added to the Netscape package to ensure that Russian text in Web pages would appear on the screen as such, instead of as gibberish. There is no simple answer, in this high‐level treatment, to this specific question, but on page 142 there is a strong indication that the coding is probably according to ISO 8859‐5. (Fortunately, Russian Web sites usually offer alternative pages in English.)
The book is an extremely valuable review of these important considerations.
