Re: kernel support for non-English user messages

Timothy Miller (miller@techsource.com)
Tue, 15 Apr 2003 10:07:04 -0400


Robert White wrote:

>Message codes would be *VERY BAD* anyway. As soon as you start that, then
>you need a numbering authority and all that nonsense.
>
>However, it should be "reasonably easy" to preprocess (in the gcc -E sense)
>all the files in a kernel directory and the gather up nearly all the
>prototype strings. (you would still have the occasional person who wrote
>"char Message[] = "INode: %d invalid"; printk(Message,number);" instead of
>having the string in place as just "printk("INode: %d invalid",number);" and
>the later is easier to collect up 8-)
>
>The thing is "INode: %d invalid", as a string is easy to decompose into a
>regular expression because it is mostly-constant and the non-constant parts
>are represented with constant markers. There are a small number of
>degenerate cases [e.g. printk("Filename %s invalid: %s","Filename","invalid:
>whitespace character")] that might need to be tweaked but nothing is
>perfect.
>
>So "the magic tool" collects these imprint strings and builds a list of all
>the strings (for the translator), a recognizer-table (perhaps hashes against
>the constant leader word of each message and a regex for the message) that
>points to the also-built hash/key into the table of all of the known
>strings.
>
>

I'm working on this right now. My plan is as follows:

- Use a C parser which takes .c or .i files and searches for the format
parameter to every printk call.
- Provide that information to both a preprocessor and the printk function.
- Pipe every .c or .i file through an intermediate preprocessor before
or after going to cpp but before the compiler.
- Do automatic string replacement.

Right now, I'm hovering somewhere around 40% compression on the text.
When I have better results, I will write up a full report and post it
on lkml.

And, BTW, I will ONLY be supporting English. As far as I am concerned,
the internationalization is an concluded issue. There's no benefit to
it, and Linus won't accept it into mainline anyhow.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/