----- Original Message -----
From: Erik van der Poel <erik@netscape.com>
To: Unicode List <unicode@unicode.org>
Cc: Unicode List <unicode@unicode.org>
Sent: Tuesday, November 23, 1999 10:12 AM
Subject: Re: Multilingual Documents [was: HTML forms and UTF-8]
> peter_constable@sil.org wrote:
> >
> > that's definitely a different argument than what was
> > originally presented: "Multilingual documents are rare,
> > therefore people must not want them."
>
> I'm sorry that it came across that way. My thinking was more like
> "Multilingual documents are relatively rare, so perhaps Glen doesn't
> need multilingual documents for his current project. If so, he can use
> non-UTF-8 documents, and that would be better anyway, since the old
> browsers that people are still using can't handle UTF-8 well."
I appreciate the realism of your thinking, and everyone's suggestions, in
addition to the idealism of full multilingual support.
I had two goals and, as it turned out, they conflicted. One was to find the
most practical solution to handling form data returned from a set of
parallel forms localized into various languages.
The second was to do it by using Unicode (UTF-8) everywhere, so that I could
go multilingual if I wanted to, in addition to other benefits of Unicode.
Because of the poor support for UTF-8 (particularly Japanese Netscape
Nav/Comm 4's unfortunate choice of a non-Kanji, a.k.a. illegible, font as
the UTF-8 default) in an unacceptably high proportion of the current
installed base of clients, I'd be foolish to send Unicode to the clients.
Except in the case of intranet projects, I think I'll have to send the
best-supported encoding in each language to the clients and convert to
Unicode when it comes back for at least a couple more years.
That's too bad, because I really was hoping for a multilingual solution.
It's not so much an issue of the commonness of multilingual documents per se
as it is the generality of multilingual solutions. It's all too easy to
accidentally encode the data with one encoding and decode it with another,
to encode with the wrong encoding (i.e. to somehow get my trad. Chinese form
published in Shift-JIS), to get a page in one encoding accidentally tagged
with the meta tag for a different encoding, etc. I was hoping to use Unicode
to create simple, general solutions that would work without regard to the
actual content of the documents -- aren't we all. ;-)
>
> > there is a real market need
> > to improve Netscape Navigator's ability to deal with
> > multilingual documents (and forms).
>
> We are well aware of this need. Many Netscape developers are now working
> on the open source version of the browser, called Mozilla. This new
> version is a near total re-write, and is based on Unicode as the
> internal character encoding.
>
> However, many people are still using the old Netscape browsers, and
> since Glen is embarking on an HTML form project now, I thought I should
> give him some advice about the *old* versions, to somehow make him at
> least somewhat successful.
>
And I'm very grateful you did.
Thanks,
__Glen__
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT