> Oh, no, not again.
> Translation of kernel messages belongs, if anywhere, in userspace.
It cannot be in userspace, e.g. 'klogd', because most of the problems
happen while booting, so no klogd. My main concern was the dumb
non-english user trying to install his Linux with a German distribution
and German installation routine. Also, these users/customers can give me
more information if something went wrong (hd broke down etc), because
noone remembers messages in unknown languages - for those it looks like
random data ;-). Try to remember this: "Linux konnte keine
Wurzel-Festplatte finden"
Some of these customers have to shut down the computer and its easier for
them to understand 'System halted' than 'Das System wurde angehalten'
(swapped languages to make it understandable in english).
Another example are unconnected network cards. My card says 'No 10baseT
link beat found, switching to AUI media.' If you know, you have 10baseT
and get this message, you might fix it on your own. I know a system
administrator adjudant (hehe) who doesn't speak english (and doesn't see
colors, but this is something different...Once I showed him the new
features of Netscape 4.0, colored eMails, sent him an eMail and asked him
if he noticed the green 'Hello'...Aften that I knew his handicap ;-) )
Finally, not everyone's English is perfect and I often had to look
the messages up in a dictonary.
> Putting it in the kernel would (a) bloat the kernel and (b) make it
> harder to debug problems. (developers would have to know what
> all sorts of translated messages meant for at least their subsystem,
> rather than merely having to know the English messages.)
a) Sure, but I don't give a sh*t on my 64MB machine :-)
b) Right, but you can always disable the translation via a
'null'-translator. Still this won't fit for one-time-problems, but
problems should be reproduceable, right?
> I've been toying around with this idea off and on, but haven't done
[...]
> First off, this seems like a very good idea, but IMHO, it wouldn't be
> necessary to completely implement it. There are many such kernel
> messages that really aren't expected to stay around (debugging and such)
> and it would be a heck of a lot better for the author to not have to
> worry about refrencing string tables and adding a new string to a list,
> etc.
Your are right, comments like 'this message should never appear' aren't
subject to the first releases.
> Secondly, this has a great potential to treat English messages in the
> same manner as the foreign language ones and could end up as a
> manor/minor rewrite in the means for outputting kernel messages. You
> could probably use swappable lookup-tables that could be loaded like a
> module and configured simularly. (I'm not 100% sure of the logistics
> behind this, actually. In any case, it wouldn't be difcult to implement
> your own method of swapping in and out string translation tables.)
Maybe this ain't possible for all messages ('KERNEL-PANIC: swap failed').
> I'm thinking something like changing the standard printk into something
> like translated_printk(PK_TOKEN) where the token would refrence a string
> in the table, but printk() could still be used when no entry in the
> table is avalible or necessary. (And, heck, it could "fallback" on an
> English string if the foreign language string table doesn't contain all
> of the required strings.)
My primary goal was as less interference with the current kernel as
possible. I worked with indexed error messages on a project and it was
quite ok, but then 'printk()' is similar to 'print()', so you can but a
lot of code in it. Some kernel-messages contain strings that have to be
translated, too, e.g.
printk( "Mounting root device (%s)%s", whoknowsstring, bRO ? "read-only" :
"" );
For this I implemented a feature that feeds the 'sprintf()'-ed string
again into the translator but remembering the original hashvalue to find
it again.
Token tables are harder to use and you can achieve the same goal with a
tool that replaces the strings in the source-codes. You cannot apply any
patches after that, but the kernel is tight! I wanted to implement the
language-files as a database, but didn't know how to implement the feature
mentioned above.
> Well, apologies if I spoke below you level as it were, I'm just giving
> you some of my thoughts on how I was considering doing something
> simular. I'm sure that you have already come to your own conclusions,
> probably more thought out than mine. :) I'd appreciate hearing about
> whatever progress you might have and if you ever are looking for a beta
> tester or another viewpoint, let me know.
I'm not god (at least not yet), so comments welcome! Linux lives from
that. The translator-patch itself is very small, so not much beta-testing
should be needed. More important are translations and the tests of them,
especially if a small routine is needed to translate (e.g. plural-s).
> ps If you implemented the English strings in the same method as the
> foreign strings, your '400K' loss wouldn't really exist.
right, see above.
> > Problem:
> > Linux kernel messages are english only.
> Don't believe this is problem: Kernel messages are not meant to be
> displayed, normally. You have to be kernel hacker to understand
> them. And any non-boot messages could be translated by klogd - no need
> to make kernel bigger...
see above
> [And - even if you translate them - what about messages like 'Penguin
> instruction in penguin more'? You _can't_ translate them, becuase they
> do not mean much even in english...]
Yes, these might stay in English. As I said, my problem was the 'System
halted' message. Linux is spreading to the non-guru-user, so the
kernel-messages should be understandable. I always remember the OS/2 error
messages when you put a disk formatted under OS/2 but no boot-sector into
a booting PC. Something like
OS/2 81032!!
OS/2 71601!!
hel[pl] knows what this means!
Kurt
P.S.: Last but not least, my girlfriend likes it, because she doesn't
speak English. This should be the most important reason above all others!
-------------------------------------------------------------
Step 1: Find the plan!
Step 2: Save world! Let's get crackin'...
Step 3: Get outta my house!
My eMail address has changed --> kurt@huwig.de