Am 1999-11-24 um 10:37 hat Marco.Cimarosti@icl.com geschrieben:
> John, il limerick francese ("Une jolie epousette...") non era necessario: la
> citazione di Coleridge contenuta nella "signature" della tua e-mail
> ("Schlingt dreifach...") costituiva già un esempio sufficiente di documento
> multilingue...

And yet, ...

> The fact is that "multilingual documents" have never been a problem, as far
> as all the involved languages share the same character set.

...the German quote (Coleridge, translated) has presented a problem to John,
which he has solved by resorting to a non-standard spelling  ("schliesst"
rather than the correct "schließt"). Also Marco's remark (quoted above)
contains some non-ASCII characters, as does John's French limerick.

So, even those superficially "mono-script" examples are really
"multi-script", to some extend; and they require techniques
developped for processing multi-lingual content, in this case:
- the MIME protocoll (as the underlying SMTP allows but ASCII),
- Latin-1 (rather than ASCII) fonts,
- particular keyboards, or input methods,
or alternatively (as in John's Coleridge quote)
- resorting to less-than-adequate Ersatz (surrogate) representations.

This illustrates an all-too-common misunderstanding:
Most users take for granted that the characters they are used to
are processed correctly by the systems they use;  in other
words, for most users a character is a basic entity, unrelated
to any technical issues. Hence, most users cannot imagine
that there could be technical problems, such as diverging
internal representations (and pertinent code-converions),
limitations of the character repertoire (such as non-ASCII characters
in Latin-based scripts),  or limitations of the fonts used for display.
The only problem most users can see is the occasional missing key
on a foreign keyboard.

Am 1999-11-24 um 14:03 h hat Chris Pratley geschrieben:
> I should also note that in surveys users always rate multilingual pretty low,
> even outside the U.S. Despite the biases of this mailing list to the
contrary,
> multilingual is just not such a hot item in the real world when you stack it
up
> beside the web, game support, stability, performance, etc. that everybody
wants.
> In isolation, of course the answer to "Do you want multilingual support?"
> is a fairly strong yes, but if people have to trade it against other
features,
> it goes down the priority list.

So the question should not be  "Do you want multilingual support?",
but rather:
- To a German user: "Do you want the 'ä' you have typed to display
  and print as an 'ä', even on a different computer, e. g. your E-mail-pal's?
  (You cannot say pen-pal, in this case, can you?)
  Or can you live with
  - remembering to type "ae" rather than "ä", in every single instance,
  - bearing with hard-to-read surrogate representations, such as
    "Traeume", which would be read as "T-r-a-eu-m-e"  (a non-existent
    word), but is meant  as "T-r-ä-u-m-e" ,
  - wrong renderings, such as "Trdume", "Tr{ume", or "Trõume",
    whenever you forget to type the surrogate representation?
- Likewise to a user in another Latin-1 language,  mutatis mutandis.
- To a user of another ISO-8859-series language: similar questions,
  plus a question covering Latin characters substituted for national
  ones (such as an ISO 8859-7 Delta becoming a Latin-1 "Ä").
- To a user of a non-8859 language: similar questions plus
  many more covering the various compatibility, and implementation
  problems.

In my environment (university in Germany, close to Switzerland),
I consistently find that
- some users are content with the surrogate representations,
  mostly type "ue", even if "ü" is available, but inadvertendly
  send an occasional "ü" through channels where it will be
  mangeled;
- other users simply expect German national characters to work
  everywhere, and are quite surprised if they experience failures
  (as the examples above); these userers also tend to be unhappy
  with surrogate representations received from elsewhere,
- there is but one ;-) user, viz. me, who tries to find and mend
  transmission errors, to configure character-handling correctly,
  and to tell the rest of the world how to do it right.

In a nutshell: a significant part of computer users expects
computers to do their text-processing "just right"; to
assess the importance of i18n (and proper l10n), you have
ask the right questions.

Best wishes,
   Otto Stolz

PS. Those examples of wrong rendering are not made-up
but based on all-too-common experience.
- "Trdume": E-Mail sent  8-bit, Latin-1, encoded,
            as seen after passing through a 7-bit SMTP channel;
- "Tr{ume": DIN 66 003 (German national ISO 646 variant),
            as seen on an ASCII (or ISO 646 IRV) display
            (this one is a bit dated, I admit)
- "Trõume": ISO 8859-1 (or Microsoft CP 1252),
            as seen on an CP 437, or CP 850, display --
            a common situation on a PC: text entered
            in a Windows application, then displayed in a DOS window