One of the latest bright ideas to go around on the linux-kernel mailing
list is that the messages printed by the kernel should be presented in the
local language. After all, the rest of the system can be localized, but
the kernel remains firmly English-only. Wouldn't it be better to complete
There are a number of approaches one could take to this sort of problem.
One would be to have the various printk() strings available to the
kernel in all supported languages, with the correct one selected at run
time. One need only look at what that approach would do to the size of the
kernel to reject it outright. Trying to support a compile-time language
option seems impractical at best.
And besides, Linus has been quite clear on
what he thinks of in-kernel localization support:
The answer is: go ahead and do it, but don't do it in the
kernel. Do it in klogd or similar.
So would-be translators are forced to look at user-space solutions. Riley
Williams posted one possible approach: add a
unique message number to each message printed to the kernel. Format
strings passed to printk() are already expected to begin with a
string like "<2>", which provides the log level of the
message. Why not put in, instead, something like
"<2.12345>"? User-space translation code could then use the
message number to index into a file of localized messages.
The devil, of course, is in the details. In the 2.5.67 kernel, there are
almost 52,000 details (in the form of printk() statements). It is
hard to imagine anybody having the patience to go through and assign unique
message numbers to each of those statement. It's even harder to conceive
of anybody being willing to translate that many messages into even a single
other language. They do not make the most exciting reading material,
especially since all the really good profanity is restricted to code
comments. There are very few prospective translators with an itch that
requires scratching that strongly.
Now try to imagine that whole structure of message numbers and translations
surviving past more than about two minor kernel releases. Each new message
would require a new number; just administering the number space would take
quite a bit of somebody's time. Translations would have to keep up with
changes to messages. Bear in mind that the 2.5.67 patch, alone, affected
824 printk() statements. 2.4.20, amazingly, affected more than
6,000. This system would be entirely unmaintainable.
So in-kernel support for internationalization is unlikely in any form.
Whether it can be done entirely externally is another question; Linus suggests trying to translate the messages
directly from text. That, probably, is a way of saying that it will not
happen at all. But one never knows...
to post comments)