> There are two options here - either allow for dynamic changing of
> language, which presents a few problems, not of which are insurmountable,
> or compile the new language directly into the kernel. Personally, I'd
> prefer the latter option, as it will be simpler to implement and maintain.
Please, do not do it ! Whatever language we present messages to the "end
user", there must be a possibility to see and save original, English
messages.
In general, I am against programs which are not able to communicate with
people and _other_programs_ in English. National language may be an
additional feature, BUT NOT the only available feature. Having such a
nationalized program or operating system is a real disaster (I am Polish, and
I really understand better English versions of programs like MS Windows then
their Polish translations).
Let us assume that someone writes a very clever script analysing
/ver/log/syslog and undertaking varius actions. You change language - it will
be broken. (Like Internet Assistant for Polish and most other versions of MS
Word (even the macro language there is in Polish ;-) )
Developers: if you accept national language support in Linux kernel, be
prepared for analysing debug logs in all supported languages. (Your
answer would be probably: "Compile English version of your kernel, and
reproduce the bug!")
Users: be prepered to translate manually all your kernel messages to English,
in case something goes wrong and you want some help.
Therefore I would suggest creating an additional stream of kernel messages
from klogd/syslogd and passing it through some filter (hash table based on
translation file, as suggested before). That filter could send the
messages in different languages to different consoles. But messages should be
still saved on disk in English.
Please reply only directly to me. Save the bandwidth on linux-kernel for more
relevant topics.
-- Tomasz MotylewskiP.S. Someone wrote "like it is done in Windows NT". Well, we are here not to emulate every broken feature of Windows NT.