----- Original Message -----
From: Chris Pratley <chrispr@microsoft.com>
To: Unicode List <unicode@unicode.org>
Sent: Wednesday, December 01, 1999 8:07 PM
Subject: RE: Multilingual Documents [was: HTML forms and UTF-8]
> The need for explicitly multilingual documents is not as great as many of
us
> would wish. If any of us work in companies that make software that could
be
> more multilingual, my advice is to not push some imaginary great need for
> multilingual support as the main reason that products should be made
> multilingual. You risk being dismissed as having a lack of perspective on
> the big picture of customer needs (as Andrea describes).
I'm still of the opinion that the need for "multilingual support" is not a
function of the need for "multilingual documents". In most cases, the need
to be able to manipulate text data in a language-independent way comes from
something other than the need to create "multilingual documents" per se, as
you point out below.
> I had much more
> success within Microsoft for Office97 and 2000 by arguing that:
> 1. A single code base and executable that handles all customer languages
is
> easier for a development organization to maintain (Strictly speaking this
> does not require multilingual support, but that helps a lot in internal
> processes, testing, etc.)
> 2. The cost of shipping a product is not just that of the English version,
> although it may seem that way to the "core" development team. By
globalizing
> the code, all the downstream (localization) costs are reduced, and quality
> increases for non-English products. (~53% of sales by value for Office).
> This argument is even better because it shows you are thinking with an
even
> bigger perspective than your detractors.
> [Etc.]
Exactly. It's that "bigger perspective" that led me to the question that
started this thread: how to get HTML forms, regardless of their language, to
submit data to the same CGI/server-side processor in the same,
language-independent encoding: UTF-8. In other words, how to reduce the
marginal cost of doing something in a new language.
This came about because a very successful company, with sales and marketing
people all over the world, is constantly having to say, "no, sorry, we don't
have the resources" to innovative ideas from its own marketers. The problem
is not that anybody is demanding "multilingual documents". It's that the
underlying infrastructure isn't language-independent, so every request for,
say, a customer survey for Korean customers is a special case that won't
work within the "normal" system and, hence, demands more resources than it
alone can justify.
When you have several hundred special cases, you can't afford any of them.
When you have hundreds of specific instances of the same general case, you
can do them all. The latter requires a language-independent (which you might
call "multilingual") infrastructure, which requires that *all of its
components* be language-independent.
When considering the economics of multilingual support, I wish that more
vendors asked themselves "would this product function as part of a
language-independent system" rather than "how many times are our users going
to want to create 'multilingual documents' with this?". (Programmer
punctuation intentional.)
Perhaps the best approach for all of us on this list would be to speak (and
think) in terms like "language-independent", or "lowered marginal cost of
future expansion", rather than "multilingual" when presenting our cases for
Unicode.
Glen Perkins
[And, yes, I realize that language independence involves more than just
using Unicode.]
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT