Re: kernel support for non-english user messages

[Frank Davis]

How about unifying the printk text messages into a limited set of 
common/canned text statements? If that could be done, all that would be 
needed in the kernel would be a small language translation table. The 
output of the table, based on the english input and the user's language 
setting, would be sent to the administrator/user.

On a similar note, Andreas Dilger mentioned this suggestion earlier, 
which it seems has been echoed by others, and that might be agreeable...

"My suggestion would be to add the required i18n support to klogd, so 
that kernel messages are translated as they are removed from dmesg into 
syslog. Then, like any i18n support, you build a message catalog from 
the printk strings in the kernel and have klogd do the 
lookups/translation in user space."

Regards,
Frank

Werner Almesberger wrote:
> Matti Aarnio wrote:
> 
> Nobody is going to maintain all the translations of "his" component,
> so you might as well let the translators try to play catch-up, and
> track changes in their regexp database.
> 
> For the kernel, we don't have the mechanisms of big companies or
> monolithic projects to just funnel all changes of a specific kind
> through a single channel, where somebody slaps a unique message-id
> on them.
> 
> Granted, you can have multi-level messages (like the VMS-style
> %facility-severity-ident), but that only buys some time. And you
> still either need a message catalog or include the plain text in
> the message as well.
> 
> The message catalog only approach wouldn't work well for the kernel,
> yielding either too many files or patch congestion on central
> message files. Think of Documentation/Configure.help and the
> relative frequency of changes.
> 
> And if you have the (English) plain text, you almost always also
> have your unique message key. At least unique enough for
> translation. So perhaps it's time to forget the traditional
> solutions, and think of a more distributed approach.
> 
> - Werner
>