It started with an invitation from a specialised agency of the United Nations to provide language facilities in English, French and Chinese for a regional conference to be held in Apia, Western Samoa. For such conferences throughout the world, it is usual for both interpreters (of the spoken word) and translators (of the written word) to be recruited and transported to the conference venue. Also the staff and equipment needed to produce and print reports and documents are located at or near the conference venue.
To efficiently render translations with the required terminology, translators increasingly use computer-based word processors. They often rely heavily on texts and glossaries associated with a particular organisation or subject and specialised dictionaries in the various languages.
To reduce the cost of providing these facilities it was decided to have the translators work remotely at their normal place of business and to communicate with them via e-mail. This has the advantage that the translator is working in a familiar environment with customary aids and ready access to others. It was estimated that about 20,000 words would need to be translated. For this conference the Chinese translations were done in Beijing, where the standard time was six hours behind Apia, and the French in Sydney, where the time was three hours behind. Both places were also across the date line from Apia.
Several communication problems had to be overcome, and this work started months before the conference was due to start. The headquarters of the agency are in Europe and initially the reports of the last regional meeting were e-mailed to Australia. Our facilities included both Macintosh and IBM compatible computers. The first files were downloaded to the Macintosh and thereafter followed a search for software to decode UUE encoded document files. It was discovered that there are various bases for UUE codes.
To explain what this means one needs to load the file into a word processor such as MSWord – or even Notebook for small files – and examine the start of the UUE encoded file, where for example the first line is of the form “begin 600 filename.ext”. The following lines each contain 60 characters and start with a capital M. It is useful to know this file name as it is often different from the name of the encoded file. Also when the file is decoded it is helpful to know what you are looking for, even if you have configured the decoder to put the file in a known directory.
Decoding software such as “Extract”, “Wincode” and “UUECODE” (the latter hav-ing a range of decoding formats) were not at all happy to decode to the base “600” in which the files were encoded. What would you do? A test file encoded by “UUECODE” showed that the first line contained the number “644”. When the “600” in the document files was changed to “644” the files were decoded nor-mally. Further research confirmed the validity of the use of “644”. The number belongs to the UNIX system where file permissions are set by the binary content of each digit. The file owner’s permissions are set by the first digit, “4+2” allowing “read” and “write” access. The “4” for the two other digits allows a “group” and “others” to read the file.
This work was done by transferring the files from the Macintosh to the IBM compatible. Later, software was found which would decode the “600” based files in a flash. Although “644” compatible software was found for the Macintosh (“UULite 2.0” is an example) the results were not as certain. The decoded files were transferred back to the Macintosh and Word to allow printing to be done on a laser printer. The question may be asked: “Why encode files?”. The short answer is that if you don’t encode, the e-mail system will encode to remove the eighth bit from bytes.
Problems can occur when the receiving terminal is not expecting “MIME” or “binhex” encoded files. For example some Macintosh e-mail software was found to have “binhex” and other Apple methods but not “MIME”. It was difficult to recover WORD files sent from an IBM compatible, “MIME” encoded, and received via e-mail on the Macintosh. Therefore it appears to be safer to encode before passing a file to the e-mail system, and if possible to arrange to use the same or a compatible decoder after receiving the file from the e-mail software. In fact both methods were used, and because the computers used were all IBM compatible, no problems of this type were encountered. The files from Beijing were “UUE” base “600” encoded and those from Sydney “MIME” encoded and decoded by the receiving e-mail software. This appeared to take place after reception of the file and caused the time for the connection to be prolonged and was therefore more costly. The e-mail server used by the conference secretariat was located in Bangkok. The staff of the secretariat at Apia had available two Notebook IBM compatible computers (each with a direct exchange line) which they used for the e-mail communication with the Chinese and French translators.
Our communications were sent separately via an OzEmail server in Australia. The availability and quality of the telephone connections in Apia were excellent. Our Notebook was connected through a Maestro FM144 modem to the telephone outlet in the hotel room and operated without fail. To accommodate the short delay this introduced, the dialling sequence in the e-mail script was altered to included a delay between the “9” and the ISD country code and the remainder of the number.
The most difficult problem follows, that of printing the Chinese characters in the files sent from Beijing. Enquiries of local (Australian) translators of Chinese identified two pieces of software which, when loaded into an IBM compatible, provided true type and other Chinese fonts which automatically became available to Windows software such as Word, Write and Notebook. These programs are Union Way and Chinese Star.
A demo copy of Chinese Star and an Asian Pack version of Union Way were obtained from the World Wide Web sites listed below.
The Chinese Star was acquired by great persistence and patience . Each of three zipped files was about 1.3Mb+ in size. Often the downloading was terminated by a peer, usually when the file had reached more than 90% completion.
The choice of Chinese Star for Windows and Word for printing the Chinese files was dictated by the decision to use the same software as being used in Beijing. The final results were judged to be very satisfactory.
It was of great help to have a Chinese interpreter preview the pages before printing because the Chinese characters may be associated with more than one byte. Word sometimes separated bytes, leading to incorrect characters being formed at both sides of the wrapping point in the line. By critical examination and reducing the font size these display errors could be detected by a person without experience of Chinese. However judgements regarding the various fonts and the layout were best done by a Chinese literate person with experience with the software.
A point vital to the success of the exchange of texts for translation via e-mail was to have confirmation of the reception of messages both to and from the remote translators, regular checks of the mailboxes being necessary. Voice and facsimile facilities should also be available for immediate communication when difficulties arise.
The assistance give by Mr. Chris Hampelé, Computer Consultant visiting from the U.K., Mr. A Glen of Maestro Pty Ltd and Mr. Tim Conboy of OPTUS is gratefully acknowledged.
Chinese Star
http://www.suntendy.com/cstar/downfile/demo1.zip
Back to Oct 1996 Index