[lkml]   [1997]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Jive -> Kernel (International Linux)
>> 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.

My previous message on this topic proposed a way to view log files in any
language. If you suddenly decide you don't like the Polish translation of some
error messages then you could easily view the messages in English.

>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).

I agree. You shouldn't have a choice of language at install time (a choice
you are later stuck with). You should be able to change languages at any time.

>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

>Users: be prepered to translate manually all your kernel messages to English,
>in case something goes wrong and you want some help.

There is a simple solution to these 3 issues. Give every error message a
unique number. In a previous large project I worked on (>900K lines of code)
we had unique error numbers for all messages. When bug reports came in they
were analysed based on error numbers (and we used the text messages just to
verify that we had been given the right number). I think that a similar system
would work well for the Linux kernel.

>P.S. Someone wrote "like it is done in Windows NT". Well, we are here not to
>emulate every broken feature of Windows NT.

Not every feature of NT is broken, they do get things right occasionally.
If we are going to start avoiding putting features in Linux simply because NT
got them first then we might as well give up and join the crowd of computer
journalists chanting "NT is the future".

You will note that in my previous message I did not recommend doing logging
the same way as NT does it. What I do advocate is taking the best of the
current NT and the Linux approaches to create a new type of system log that is
more powerful than either.

Russell Coker

 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2011 Jasper Spaans