Re: kernel support for non-english user messages

[Ville Herva]

On Thu, Apr 10, 2003 at 04:06:36PM -0600, you [Andreas Dilger] wrote:
>
>   From what I've read, it sounds like the solution that will be accepted by
> the kernel developers is that kernel messages will continue to be output
> as-is in english, and can be post-processed with a tool to translate it to
> another language.  The tool will grab the format strings from the kernel
> so that it can separate out the constant and variable parts of the message,
> and the format strings will be translated.
> 
> At translation time, _something_ _like_ "sscanf(format_string, ...)" will
> be used to detect the which message is which (probably being speeded up
> with a pattern-matching hash of the constant parts of the message like
> prcs/xdelta does), substituting the english format with the translated
> format, and then substituting the args.

But the sscanf parsing is fragile if not impossible to get right in some
cases. How do you parse the output of printk("file %s on device %s
corrupted", file, devname); if file the file contains spaces and whatever?

Why not make it so that kernel can be configured to output messages as
<format string>,<arg>,<arg>... where the format string is what is usually
passed to *printf. (The actual field separators could be \0 or something.)
Then you can use standard gnu gettext to get the translation in user space
(i18n aware klogd, whatever) and apply the formatting after that.

Actually, the structured message pool could be separate from the normal one,
so that the existing tools don't break. Both the old style and formatted
message pool could be configured on and off based on user needs when
compiling the kernel. 

And the change should be pretty easy and centralized in kernel. This only
adds the run time over head of maintaing two pools iff both are configured
on.

(Not that I need i18n kernel or would ever use one. And I'm fairly sure
no-one gets around to implement it anyway...)

-- v --

[e-mail]