On Fri, Dec 22, 2006 at 08:12:52AM +0100, SZALAY Attila wrote:
> > Why would you *not* want a locale? If the program has l10n support and it
> > provides messages (even in a non-interactive way) there's chances some users
> > will benefit from the translated messages.
>
> In log files, localized messages may hurt more, than what gain with it.
>
> For example some (semi)automatic log analyzing programs couldn't (and I
> think don't want to) handle localized log messages.
IMHO, either that software should be modified to support i18n text or the
admin would have to choose wether he prefers to *understand* the logfile or
to be able to parse it with automatic programs (I believe you are talking
about tools such as logcheck or log-analysis [1][2]).
In any case, it would not be too difficult to adjust programas that parse
logs to be able to parse translated messages. Take in account that all
translated text messages would be available in a message catalog (typically a
PO file).
So it could be realy straightforward to convert a text mesage like this
(from logcheck's kernel violation.d rules):
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: [[:alnum:]]+: media error \(bad
sector\): status=0x[[:xdigit:]]+ { DriveReady SeekComplete Error }$
to the Spanish equivalent of:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: [[:alnum:]]+: error en el medio
\(sector defectuoso\): estado=0x[[:xdigit:]]+ { DriveReady SeekComplete Error }$
if the kernel's Spanish PO file has something like:
msgstr "media error (bad sector): status="
msgstr "error en el medio (sector defectuoso): estado="
Or even have logcheck use those PO files directly by introducing some tokens
in its regexps.
For those logparsing programs that would not had i18n support, the user (or
admin) would at least have the *option* to make a decission.
Consider this situation: a user that can not even *read* english (since he
doesn't understand the written language as he uses different script) should
be able to weight which option is more important to him:
a.- be able to use software that generates reports from logfiles with english
messages, and not being able to understand the logfiles themselves and
(probably) not the reports either (if the reporting software is not i18nised)
b.- be able to read the non-english logfiles, but unable to use software to
geenrate reports or summarise logs (until such a software is adapted to
support non-english messages).
What would you chose?
Regards
Javier
[1] There is other more domain-specific log analysis tools (for webservers,
firewalls and mail servers) in Debian but many of that software users
logfiles in a standarised (or propietary) format that is not (typically?
easily?) parseable by humans.
[2] Or Sawmill (but, even if it's a really good and cheap log analysis tool
it still is not free and, consequently, out of our scope)
Attachment:
signature.asc
Description: Digital signature