Youre still missing the point, in english.c youd have this:
#define SCSI_MSG(s,a) "SCSI driver using buffer of size %d at %d",s,a
In jive.c youd have this:
#define SCSI_MSG(s,a) "SCSI driver be at %d, and it be %d bytes big",a,s
And the code would still be:
> It gets worse, though, because in many languages there are also issues
> of noun/verb agreement where some words depend on the case, gender, or
> number of the substitutions. While dealing with randomly substituted
> numbers is probably much easier most of the time, it's not something you
> can completely ignore if you want the translated text to be readable.
This problem, although valid, is not a problem with internationalizing the
code, its a problem of writing any software in language X, IE it would be
hard to use substitutions at all in language X, so how to make it seem
natural is the job of somone who knows the language... I mean, what would
somone do if they were actually writing a program in that language from the
start? Give up? Pick another language? No, they'd probably settle for
slightly less flowing grammar as long as it gets the point accross, you see
this example all the time on english software... ie: "You have 1 new
> Umm, if the string constants are compiled into the kernel, then any
> software that monitors kernel messages has to know what they are in
> every supported language. Nothing so far indicates that there is any
> attempt to provide runtime-switchable languages for kernel messages.
Software that monitors the kernel messages already monitors it in
"generic" language... therefore, you'd just continue to use it in generic
language... even if you wanted to have an international kernel and have it
be monitored.. the language .h files are just available to you as they are
to the kernel. It wouldn't be trivial, but then its making your monitoring
program bi-lingual.... so adding a feature like that isnt trivial anyway...
just leave it in generic if the languages break one of your programs...
"God is real, unless declared integer."