I would classify all of Asmus's examples as what I referred to earlier as
"publications", i.e. a small subset of documents that are intended for mass
distribution to unspecific audiences. They don't represent a large number of
unique documents but they are distributed widely so they represent a
somewhat disproportionate share of physical instances of documents - which
is somewhat but not entirely irrelevant to the authoring frequency and
therefore the issue of support within applications. One could argue that
these wide distribution publications are more "valuable" to customers on a
per-document level than memos or letters, so there is some reason to weight
them more despite their relatively low frequency.
That said, I don't want to drone on about multilingual not being important,
since I personally don't feel that way (business is one thing, my interests
are another). I think the point I was trying to make on this thread was:
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 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.
3. A single executable that handles all customer languages is much easier
for customers to handle (Large organizations in particular). This reduces
their cost of deployment and administration, and can be translated to real
business value for them.
4. A single executable implies a single patch for fixes rather than
language-specific patches, which further reduces customer hassle and cost.
5. The headache of identifying and handling the various multilingual
customer scenarios that actually do exist all go away if you use Unicode
rather than try to hack your product to support.
Customers have responded very favourably to these points and the resulting
product, so that helps in support of continuing the work in the next
release.
I find it ironic that the biggest driver for multilingual support, and
therefore Unicode support, and thereby support for minority languages in
mainstream software, has been the needs of large "faceless multinational
corporations" - the same ones that are often vilified for trampling smaller
cultures. Funny how things seem to work out in the end.
Chris Pratley
Lead Program Manager
Microsoft Office
-----Original Message-----
From: Asmus Freytag [mailto:asmusf@ix.netcom.com]
Sent: December 1, 1999 5:46 PM
To: Unicode List
Subject: Re: Multilingual Documents [was: HTML forms and UTF-8]
Chris suggested that we on this list have a bias in favor of multilingual
documents. I think, we tend to have a reverse bias, overlooking the
existence of very everyday multilingual 'documents' that surround us. Even
in the solidly monolingual US.
Following suggestions from earlier postings I'll focus on those
multilingual documents that cross one of the technical boundaries that
non-Unicode systems erect.
1) My utility bills in Seattle are printed in these languages
- English, Spanish, Vietnamese, Chinese, Korean, Lao and Thai.
(on the same bill).
2) Some of the foods (and other goods) I buy come with packages that contain
- English, European languages, even Arabic
(These are not necessarily 'ethnic' foods, but the packages are
intended for export. Extreme combinations of languages are more
common in some markets, those that get the 'Rest of World' package
as seen from the perspective of the producer)
3) Instruction and safety booklets come with almost any juxtaposition of
languages.
4) Most of my (European) newspapers easily cross alphabet boundaries
(e.g. use of correct Latin-2 accents is common in Latin-1 languages).
I'm not listing the dictionaries, foreign language works, etc. that are all
specialized multilingual documents that I own because I am a member of this
list (or is it the other way around?) but ordinary everyday documents that
I did not particularily seek out for their multilingual nature. (This is
true even for (4).
Somebody has to produce all of these. For that purpose it would be enough to
have the translators use special purpose software. But just as with the
problems of German e-mail in a mixed 6/7/8 bit e-mail infrastructure, this
scenario runs into problems as one finds oneself reduced to manipulate
pictures of translations in the rest of the production process. And that is
how many of these things are done.
I appreciate Chris' attempt to not overstate the case for multilingual
support, but as we become more dependent on the web and net infrastructure
to handle all our text processing, the remaining bottlenecks do tend to
have a 'reverse synergy' type cost to them. My theory is that these
bottlenecks prevent some users from fully adopting the new technologies.
This 'cost' probably scales more with the percentage of users who have to
waorry about identifying and managing work arounds for them, even if
infrequently, rather than merely with the straight percentage of documents.
A./
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT