Mind to Mind

The Multilingual World Wide Web

The Multilingual World Wide Web

Original HTML version


Table of Contents


Introduction

The World Wide Web has enjoyed explosive growth in recent years, and there are now millions of people using it all around the world. Despite the fact that the Internet, and the World Wide Web, span the globe, there is, as yet, no well-defined way of handling documents that contain multiple languages, character sets, or encodings thereof. Rather, ad hoc solutions abound, which, if left unchecked, could lead to groups of users suffering in incompatible isolation, rather than enjoying the true interoperability alluded to by the very name of the World Wide Web. This paper discusses the issues, and hopes to offer at least a partial solution to the problems discussed.

Please Note: The opinions of the author do not always agree with opinions found in this document. At times the author has tried to represent the opinions of others for completeness’ sake.


1. Requirements for multilingual applications

Many things are required of a system claiming to be multilingual, though they generally fall into one of 4 categories:

  1. Data representation requirements
  2. Data manipulation requirements
  3. Data display requirements
  4. Data input requirements

In the following, the requirements within each of these categories is discussed.


2. The WWW As A Multilingual Application

While most people view the WWW as a large collection of data, servers, and browsers, the author prefers to look at it as a single large application. Each component of the WWW is really nothing more than an object in the most dynamic, and fastest growing, distributed application on the Internet today. Just as all components within a given application can communicate with one another, the authors’ overriding goal for a multilingual WWW can be stated as:

From an end-user perspective, no matter where a link leads, the browser will be able to cope intelligently with the data received. From a system viewpoint, all clients and servers should be able to at least communicate.

By looking at the WWW as a single application, it is quite obvious that the needs of the WWW are almost exactly the same as those in the previous section. In the following, we will discuss each category of requirements as it applies to the WWW, and present unresolved issues facing the WWW today.

3. Issues Facing Multilingual Support in the WWW

From reading the previous sections outlining the requirements for multilingual applications, and for a multilingual WWW, it should be (somewhat painfully!) obvious that the WWW falls quite short of the mark. Below the more important issues are outlined.


4. Possible Solutions to the Issues

Now that the requirements, and the issues have been explained, it is time to turn to solving the problems discussed. Below are a series of possible solutions to each of the problems raised above.


5. Recommendations

With the background and explanations above, we now turn to specific recommendations that would allow multilingual data processing in the WWW. Backward compatibility has been kept in mind.


Discussion


Appendices

The following are a series of informational appendices.

A-1. The SGML Processing Model

Status under construction.

A-2. Conversion Servers

Larry Masinter had a very good short-term solution to the problem of document exchange. In this basic model, not all servers can perform the required translation from the data storage character set and encoding of the document, to the character set and encoding desired by the client.

Rather, when a server gets such a request, it sends a redirect to the client, telling it to connect to a proxy server which can perform the translation. This is obviously somewhat inefficient in terms of network use, but has a redeeming value of not requiring all servers to perform character set translations. It seems quite likely that, at least initially, there will not be a great demand for character set translation, so this service should suffice as an intermediary step.

A-3. Implementing Unicode

Status under construction.

A-4. Problems With Unicode

Status under construction.

A-5. Problems Facing ERCS

Status under construction.

A-6. A Simple VM for use in Conversion

Status under construction.


Glossary Of Terms


Bibliography

The Plan 9 Papers
ftp://netlib.att.com/

East Asian Character Set Issues: A Proposal For An Extended Reference Concrete Syntax
Rick Jelliffe, ricko@allette.com.au, Allette Systems, Sydney, Australia

The SGML Handbook
Charles Goldfarb. Oxford University Press. ISBN 0-19-853737-9

The Unicode Standard, Version 1.1
Version 1.0, Vol 1 (ISBN 0-201-56788-1), Vol 2 (ISBN 0-201-60845-6)

Using Unicode with MIME
D. Goldsmith — RFC 1641

UTF-7: A Mail Safe Transformation Format of Unicode
D. Goldsmith and M. Davis — RFC 1642

MIME (Multipurpose Internet Mail Extensions) Part 1
N. Borenstein and N. Freed — RFC 1521

MIME (Multipurpose Internet Mail Extensions) Part 2
K. Moore — RFC 1522

Hypertext Transfer Protocol – HTTP/1.0
T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen — draft-fielding-http-spec-01


Gavin T. Nicol
Electronic Book Technologies, Japan
1-29-9 Tsurumaki, Setagaya-ku, Tokyo 154, Japan
+81-3-3706-7351 · gtn@ebt.com

This document in no way reflects the opinions of Electronic Book Technologies. Everything contained herein is solely the result of work conducted by the author during non-working hours.


The author would like to extend special thanks for Rick Jelliffe for the many useful exchanges of information.


Brought to you by the letters P, S, G, M and L, and S and P.


Tags: