What Glen expresses below is what I had tried to capture with talking about
the cost of the 'negative synergy' that comes from lots of little roadblocks
in the infrastructure. HTML forms are certainly one of the worse current
>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
>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
>[And, yes, I realize that language independence involves more than just
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT