Ack! We hashed this out a few months ago!
Summary:
(1) Kernel messages don't occur often enough to be worth setting up
translation tables, etc.
(2) Kernel messages in 100 languages makes it that much harder to deal
with bug reports (since they need to be un-translated for the developer to
know what's going on)
(3) Some kernel messages (eg, Oops's and panics) are too critical to be
kept in swappable memory (since it's a possible error spot).
Additionally, one of the nice things about Linux is that so much of its
interface is intelligible human-readable text, as opposed to other (herein
unnamed) OS's that use things like a binary registry; to rely on a
user-space daemon or translator to translate these things is a bad idea
because:
(a) versioning inconsistencies will show up: a translator for
2.1.X may barf on messages for a 2.0.X kernel, and many of us have
multiple kernels on our systems
(b) If the system becomes unstable, the binary messages may not be
logged, and the translater may not be available to do real-time
translations (what if ld.so becomes inaccessible?)
(b2) similarly for a userspace daemon - it may be swapped out and
become inaccessible/useless.
(4) Maintaining an overridable multilingual message database will either
result in massive code bloat (for non-run-time-updatable solutions) or
kernel bloat (for run-time-updatable solutions), it it would be a royal
pain in the @ss to make it an option which to compile.
In summary:
"Internationalized user programs = Good Thing.
Internationalized kernel = Not-Worth-The-Trouble Thing."
It's a neat idea, but there isn't enough practical benefit to justify the
increased complexity.
Adam
--
He feeds on ashes; a deluded mind has led him Adam Bradley, UNCA Senior
astray, and he cannot deliver himself or say, Computer Science
"Is there not a lie in my right hand?" Isaiah 44:20
bradley@cs.unca.edu http://www.cs.unca.edu/~bradley <><