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