Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Dec 2000 20:08:59 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        marcel@cup.hp.com (Marcel Moolenaar)
Cc:        mbendiks@eunet.no (Marius Bendiksen), phk@critter.freebsd.dk (Poul-Henning Kamp), des@ofug.org (Dag-Erling Smorgrav), ume@mahoroba.org (Hajimu UMEMOTO), arch@FreeBSD.ORG
Subject:   Re: %a and %A formats
Message-ID:  <200012132008.NAA10673@usr08.primenet.com>
In-Reply-To: <3A37CB39.C2E8AA67@cup.hp.com> from "Marcel Moolenaar" at Dec 13, 2000 02:17:13 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> Using indexes to refer to the arguments (vectors) has an advantage for
> i18n. The order of the arguments is related to the language and some
> translations produce better messages if the order of the arguments isn't
> fixed.

Having been forced down this route before, I can tell you that
it is an _incredibly_ shortsighted thing to do to localize
kernel messages or log messages.

A company I worked for _stupidy_ localized log messages.  The
result of doing this was that users could read the logs in
their native language, but engineers supporting problems could
not do root cause analysis, since they were trained as (this
is a "big surprise") engineers, and not as linguists.

Obviously, this was the idea of the UI folks, who wanted to
give users eye-candy so that they would be happy with their
purchase, and their idea of making this happen was to let them
look at the log messages as the code chugged along doing its
job, with no thought to support issues.


A lot of people whine about sendmail status code not being in
their native language.  Some SMTP servers actually translate
these status codes into other languages (I've seen German and
French).  Ignoring, for the moment, the _fact_ that RFC821
prohibits non-ASCI characters over an SMTP command transport,
there is no locale information about the person on the other
end of the SMTP hose.  You can't assume their language/locale
like this.

The technically correct thing to do is to translate error codes
in the MUA by providing the correct message for a given error
number, in the locale specified by the user for the MUA.  In
other words, making up for deficient mail clients by changing
the error responses is a stupid idea (the same argument applies
to decoding DSNs in a locale specific way).


For log messages, the appropriate method is to create a format
for logging that gives parametric, machine-parsable logs, and
then to localize the logs on viewing.

A secondary win to this approach is that an appropriately
modified syslogd can track state transitions in the programs
it is logging for, and then report overall status information
(ideally, via SNMP Application or Network Services monitoring
MIBs).


Kernel messages are, likewise, an issue of status or exceptional
condition reporting.  It _may_ not be justified to go the whole
AIX route and assign facility and error numbers for kernel
messages... I'd argue that most of them aren't in English,
anyway, and are untranslatable.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012132008.NAA10673>