Messages in this thread | | | Date | Thu, 19 Jun 1997 14:11:11 +0200 (CEST) | From | Kurt Huwig <> | Subject | Re: Kernel-Messages translation |
| |
> My point exactly... "Native" versions increase the linguistic > isolation, which is a Bad Thing. :-/
> > > 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! > > There are ways around this. It's safe to assume that the printk's in the > base kernel tree will always be in English, forevermore. But it is a > relatively simple matter to write a program that hunts down printk()'s and > changes arguments that are string constants.
You forget, that noone ever compiles everything into the kernel. My approach just incorporates the translations, that are needed.
> So, if someone is really interested in making a serious translation of > the majority of the printk strings, they might proceed as follows: > > 1) Do the translation work, in whole or in part. > 2) Build a hash table, or just use gperf, to go from English strings to the new > ones. > 3) Assemble a "kernel translation kit" which includes this hash and a program > that will hunt down the relevant English printk()'s and translate them. > > This would make a nice-size downloadable add-on, far superior to a huge diff.
This is, what I am working on.
Kurt
------------------------------------------------------------- If you put a PC-formatted disk into a Macintosh, you can read it. If you put a Mac-formatted disk into a Win95-PC, it asks you whether it should format it. My eMail address has changed --> kurt@huwig.de
| |