Re: kernel support for non-English user messages

[John Bradford]

> >  1. If the printk() messages are internationalised, we are going to
> >     see log extracts posted here in various languages, including some
> >     that the relevant maintainers don't understand. To stand any
> >     realistic chance of dealing with the resultant bug reports, we
> >     need to include the message code in the report so we can just
> >     feed the various reports through a tool that translates them into
> >     our preferred language.
> 
> Providing the viewer is translating the originals always exist. Indeed
> you can do
> 
> 	LANG=es view-logs
> 	LANG=ru view-logs
> 	...
> 
> You can have sysadmins with no common language("not a recommended
> configuration" ;))
> 
> You are right about needing to log parameters, but given a log line
> of the form
> 
> %s: went up in flames\n\0eth0\0\0
> 
> that can be handled by the log viewer

Wouldn't we be better off just more fully documenting the English
error messages, though, and possibly translating that explaination
document in to as many languages as possible?  A lot of people search
for error messages strings in the LKML archives, and variations of the
same string will hinder this.

On a related note, if we are going to make a dmesg interpreter and
translator, could we include the ability to generate a kernel .config
from the boot time output?  Note, I don't mean re-create the .config
that the kernel was compiled with, but something like NetBSD, (at
least), which lets you boot with a kernel that has drivers that you
don't need, and generate a config file which will compile a kernel
which contains only those that are actually needed.

John.