On Sat, 20 Jan 2007, Steve Langasek wrote: > AFAICS, post-processing of log messages would be the most reliable > method to give admins localized logs while also making it feasible > for upstreams to support user requests. Any problems that would make > it hard to post-process English logs for localization would apply > n-fold to post-processing non-English logs for translation back to > English.
But this style of post-processing would occur only when there was a support request that required an english speaker to look at the logs; the user translating it by hand in this case (or using an appropriate locale, or finding someone who could translate it or backtracking from the message to english using the same mapping that the program does) seems perfectly reasonable to me. Post-processing seems to require a set of fragile dependencies between the log processing software and the actual software generating the messages unless someone standardizes on a central repository of messages in different languages [and would make casual log checking slightly more difficult.] > For best results, we would have a logging protocol that logs a > message ID plus arguments, so that formatting into English /or/ into > other languages would follow the same, sscanf-free process. :) And a central repository of all of the message Ids and blocks which are assigned to speciifc programs and whatever other standards are needed to implement it... I suppose it would be optimal, but I don't think it'll happen anytime soon. Don Armstrong -- [A] theory is falsifiable [(and therefore scientific) only] if the class of its potential falsifiers is not empty. -- Sir Karl Popper _The Logic of Scientific Discovery_ ยง21 http://www.donarmstrong.com http://rzlab.ucr.edu
