ietf-822
[Top] [All Lists]

Re: Why do MIME imlementations sometimes fail

2003-09-27 23:49:26

The particular challenge of a format whose major feature is to allow for
multiple charsets would be to provide something that's superior to
utf-8 text/plain.

Precisely.  But Jacob is also right on target when he writes:

One interesting thing I have noted is that localized
software often works well when a user only uses his
national language, but not when a local user wants to use
another language than his own.

Even more deeply than a bias towards English, American programmers are
biased towards unilingualism, and this bias is simply translated into
any other single language.

I'm not sure of the cause, but it is undeniably true that lots of software
suffers from being simply localized rather than being fully internationalized. 

But is this a peculiarly American problem? I'm sorry, but I don't think so. In
fact, in my experience the bias towards localization (or if you prefer,
unilingualism) committed by Americans is no worse than what's been done
elsewhere.

Examples of this I've seen include:

(1) There are a large number of Japanese email clients that not only are
    highly Japanese-centric, they also adopt their own set of peculiar
    conventions for encoded word handling that doesn't interoperate well
    with standards-compliant software that supports Japanese produced elsewhere.
    There appears to be no interesting in fixing this either, which forces
    other clients that wish to interoperate to go through all sorts of
    contortions.

(2) GB18030. For those of you who aren't familiar with it, this is a *new*
    coded character set that is backwards compatible with GBK but includes
    the full Unicode repetoire. (Actually, the degree of backwards
    compatibility is somewhat debatable, since GBK only uses one and two
    octet sequences wherease GB18030 uses one, two and four octet sequences.
    I view the changes that existing GBK software will handle this well as
    remote in the extreme.) The Chinese government is mandating support for
    this in software sold in China. Now, while there might be sufficient
    justification for defining such a thing for limited applications where
    GBK compatibility is necessary. But if it comes into general use it will
    end up stifling internationalization in favor of localization.

(3) Even properly internationalized software has to provide language-specific
    text. And the expertise for doing this sort of work often doesn't exist
    within a given programming team and has to be done else, often by some
    other company in some other country. Yet I've found on more than one
    occasion that such work comes back as a total botch -- the team ignored
    the need to follow the internationalization paradigm and localized 
    things instead.

I have yet to see a mail tool (or actually
any computing environment) that does a really good job of supporting
people trying to communicate regularly in multiple languages.

Humph. I don't know if it counts, but the software I work on personally is
internationalized, not localized. Our design review process includes specific
checks to try and make sure this is so. And so does our QA process. (As a
result when testing it often suffices to install a single copy of our software
for multiple different language tests since we try and provide everything in
the base installation.)

Mind you, I don't claim our software is free from internationalization
problems. We have legacy code in some other parts of the product that is
intrinsicly incapable of being properly internationalized. We have a couple of
different charset translators -- obviously two is one too many. And so on.
There's always work to do, although I sure wish it didn't have to include so
many hacks for broken clients and support for GB18030.

Now, did this all come to pass because we're all such good network citizens at
Sun? Not hardly. The motivation for this is financial, plain and simple. A
significant portion of Sun's revenue comes from other countries. Not only do
folks in other countries demand that our software support their languages, they
increasingly demand the ability for a single installation or set of
installations to support multiple user populations using different languages
and charsets. (Globalization creates strange bedfellows, and some of the
mixtures of languages and charsets we're asked to support are fairly bizarre.)

I find it very hard to believe that other companies aren't in the same position
as Sun and haven't instituted similar development strategies as a result. It is
simply good business to do so.

Of course financial motivation does have a downside: Languages that don't have
a revenue stream attached don't get supported. (We do try and provide the hooks
so customers can do their own translations and so forth, but it still doesn't
work out of the box.) I doubt that Sun is unique in this regard either.

I seriously doubt that this is a standards issue, though -- I think
it's a combination of a cultural issue (Americans are mostly
monolingual)

Humph again. Maybe I'm just lucky, but our team includes folks fluent in
French, Mandarin, Cantonese, Japanese, several Indian languages I won't
embarass myself trying to name, and no doubt several others I'm unaware of.
Although I happen to be fairly knowledgable about charsets and the like, I'm
basically a monolinguistic ignoramus by comparison with the many of the others
I work with.

I do note that no amount of QA beats having someone on your team using your
software on a daily basis in some other language. 

and a simple technical issue: it's really *hard* to build
a good monolingual user interface, and anyone who wants to do so is
unlikely to find MIME encoding to be one of his greatest challenges.
In many cases, I think what's failing is not so much the standards as
the user interface.  -- Nathaniel

True enough. I haven't done serious UI work in a long time, and I have to say
I'm thankful I haven't had to.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>