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)
signature.asc
Description: Digital signature