Re: Kernel-Messages translation

Keith Rohrer (
Thu, 19 Jun 1997 00:20:20 -0500 (CDT)

> Stefan Hornburg writes:
> >
> > Why not add the translated messages to the original ones ?
> > So the expert sees what he wants, and the user is also satisfied.
> > If the translation is optional the configuration, kernel and other
> > bloat is restricted to the ones who want the translation.
> Because the kernel currently has 10765 printk() statements, for over
> 600k. Even if we translated all (!) of them, to just 1 additional
> language, the kernel source tree would go up by over 1 meg!
> (Why 1 meg? Well, lets do the math...)
> printk("The filesystem is corrupted\n");
> #else
> printk("Les filesystem est corrupte\n");
> #endif
And if we changed the original printk to:
and made current_subsystem_stringtable have a shorter name and be a
non-const char** (which we could point elsewhere to change languages
via insmod), we would reduce the bloat to the lengths of the
symbolic constants, plus source for the translations would have to be
made available somewhere. Any messages that weren't translated at
all would never have to hit the string tables, especially if they're
not for public consumption or don't translate (e.g. "ugh" and friends).

[code bloat whines based on the bloatiest idea I've seen in this thread
snipped...even the translate-on-the-fly ideas weren't this bad]

> Now, can we take all this bloat to a runtime translation utility?
If we want messages that come up before we leave single-user mode to
get translated, not likely.

> the
> _ONLY_ thing that should end up in the kernel is a tag that says what
> subsystem generated the printk... perhaps with a number for a userland
> interpreter. The only reason THAT sould be in the kernel is because
> find /usr/src/linux -name *.[ch] | xargs -n 5 grep "some message I saw" is such a pain.
> ;-)
Actually, getting "number tags" appended to the major kernel messages sounds
like the best idea so far. People reporting them by number can make all the
horrible typos in the message itself and we won't care. Meanwhile, people
who want to can do translation-and-explanation tables in any language
(including English) they see fit; this would give us a standardized format
for a decent portion of the FAQ, and the only part of linux you'll need to
get working in order to get a translation is the code that gives the error. :-)
This only bloats the kernel by the size of the number badges, supports an
infinite number of languages without increasing the size of the kernel or
even requiring a recompile, and works for anyone who can get documentation...

And, again, there's no obligation to translate the whole thing! None!
No matter what proposal anyone's pushing!

> Now that I have showed why this is a bad idea code-wise, and that it DOES
> lead to massive amounts of bloat, can we drop this idea for the next six
> months? Read the archives for more reasons why it belongs in
> klogd-translate.
We'll never see the kind of code bloat #ifdef french #elif defined(swedish)...
would produce: Linus knows better. There are in-kernel implementations that
don't bloat much beyond the actual added messages and don't translate on the fly;
the only code-side reason I'd rather not see them happen is that I think
we've got too much garbage like the proprietary CD-ROM drivers still shipping
with the main kernel already...