>'bofh@snoopy.virtual.net.au wrote with particular insight...'
>> Jmcc@cs.cmu.edu was known to have stated:
>> > I've been following this discussion, and it seems that the best approach
>> >would be to have a new interface to klogd, that puts out '[nn]' prefixed
>> >strings, followed by a default english interpretation. This way all
>> >translating lookup can be done in user space...
>>
>> So you are suggesting having the kernel output both English error messages
>> (suitable for straight dumping to /dev/console) and codes that klogd could use
>> to load up strings in language files? I think that this idea would work.
>> Klogd could then either pass on English strings or interpret the codes to
>> another language, or it could just store the symbolic information to allow a
>> log viewing program to view the logs in any language.
>>
> Yes, and the beauty of this is that
> a) All existing klogd/syslogd implementations will
> still work (and output readable info)
> b) We can work on internationization incrementally
> (driver by driver, filesystem by filesystem...)
> c) We'll have an easy-to-parse stream to place
> in error-logging databases
Think it is better to leave out the magic number. Just have a message database
which has the english messages and other languanged messages. Than you can do
regex pattern matching and translate the messages this way.
-- you would loose (c), it is'nt that easy to parse
++ it works without changing the kernel at all, just a filter program
where you can pipe dmesg output or your log-files in
++ It is fail-proof: If a i18n message gets outdated, matching will fail
and you'll get the up-to-date english message until you have the
message database updated.
Gerd
-- Q: What is WOM? A: Write Only Memory. Here is: l-w--w--w- 1 kraxel@cs.tu-berlin.de 9 Jan 1 19:70 .signature -> /dev/null