1. If we had a database for translations, everything would be possible.
>From patching the source over translations in kernel-space until a
modified klogd/syslogd or even a program that translates entered messages.
2. Is it possible (wanted), that there is a hook in the
'printk()'-routine, to ALLOW the modification of messages? Certainly iff
it will have no impact on speed.
3. I, personally, would appreciate german messages, as would my customers
AND my girlfriend :-)
4. Wrong, incorrect and funny translations happen, but we are not
Microsoft. We supply patches! As a Linux user I am used to 'we do
everything that has sense' and not 'we do the things that won't create
problems'.
-----------------------------------
Still, it is possible to have the hook as an 'unofficial' patch. Is there
anyone willing to translate messages into their native languages? I will
set up a database so your work won't be useless regardless which
implementation will survive. I guess
- Pavel for Czech
- Stephan Meyer for German
The database will be public readable, maybe with a HTML-frontend, so you
can enter a string and get the translation.
> But please keep in mind that we need to have a look at the kernel
> messages anyway to get "High Availability" of some sorts going. At
> least there needs to be a convention about how warnings, errors and so
> on are phrased, so that a user-level daemon can parse them. This fits
> well with providing hooks for message translation.
There are levels for printk(), from 'info' to 'critical'.
> It looks a bit ugly, but providing a numerical code containing the
> subsystem/driver-ID, status code and a message ID would be helpful for
> both issues.
Your are right. It's a pain to do a
find -name "*.c" -exec grep -l "string" {} \;
Just to find the source-code. Worse if there are several files with
identical messages (there aren't now). It would be easy to implement via
the '__FILE__' macro...and enlarging the kernel again.
> > IMHO, these things are true:
> > 1. There is a demand for translated kernel messages
> There is also a bit of opposition against any such translations.
> There are arguments against "dubbing" the kernel that prevails even if
> someone succeeds in making the implementaion fully invisible to
> english speaking admins.
>
> 1: Bug-reporting would be hurt.
> 2: Language barriers would become even greater. {The user could read
> the error message but he has spent his life using translated OSes
> so he hasn't bothered to learn enough english to be able to
> actually tell the developers about the problem}
> 3: There would be errors in the translations.
> 4: It could, in the future, hurt the OS {"Yes, L. is a Great OS but
> the german version is terribly outdated"}
Sure, there are folks against it. But in 'big' countries like France,
Germany, Spain etc. english is not as wide spread as in 'smaller'
countries, because we get native versions of Movies (I think this is
different in Belgium; they have subtitles), native versions of programs
etc. In my part of Germany, you normally learn french at school, because
we are close to France. Only those who visit the highest of 3 school
forms, the one where you get the 'licence for university :-)', you HAVE to
learn 2 languages, here two of french, english or latin.
I my family, I'm the only one who speaks english, but all of us work at
computers (ok, I'm the only one with Linux). Anything more complicated
than 'mouse not found' won't be understood.
> If someone -- in spite of the intrinsic problems -- really implements
> a translation I have a suggestion: _append_ the translation to the
> english message; do not replace.
> (e.g: "The Foo failed" --> "The Foo has failed (Foo har misslyckats)")
Append would be possible, with placeholders for the '%s', '%d' etc.,
without size increase.
> Translations should IMHO be implemented in "wet-ware" rather than
> software.
???? Hardware = you can touch it, Software = you cannot touch it, Wet-Ware
= flush it down the toilet?
> I've seen computers in Finland that had Finnish or Swedish error
> messages, and I personally always hated them intensely.
>
> That, together with the complexity of doing it for the kernel makes me
> rather unlikely to seriously consider the thing.
Is it possible to implement a hook in the kernel, where you can access the
messages?
> However, there is no reason why the translation couldn't be done in user
> space: perl is rather good at doing associative arrays, and they could
> be used to translate any kernel message into another language. "klogd"
> is your friend,
The 'trivial' and 'serious' bugs happen at boot time, e.g. no keyboard, no
network, hd-crashed etc. I support several companies running Linux and it
is hard to have them report the messages at boot time correctly, because
some of them don't speak english. So I have to go there, just to see, that
someone unplugged the network.
> > 3. The hook patch for the translator should be incorporated into the
> > kernel tree. If you don't like runtime-translation, it has minimal
> > impact on a 'kernel-messages-benchmark' (translator_proc == NULL):
> >
> > if (translator_proc)
> > hashvalue = (*translator_proc)(fmt, translator_buf, 0);
> > [...]
> > and a 'strcpy()'
> Prevent the strcpy, by doing stuff with the pointers. Or Do TWO string
> copies when doing translation (one extra).
Ok, I will modify it, so it would have two 'if's in it, if you don't want
to translate.
> I'd like to be taken off your list.
I guess everyone reads the mailing-list, so I quit CC:
> I thought that everyone except Ol' mama's knows english these days...
not in Germany.
> > I like numbers somehow, because you can easily look them up in a
> > manual...but where is the 'Linux kernel messages handbook (tm)'?
>
> There is. You take message, and do grep "message" `find . -name "*.c"`
> in right directory. Then you less that file, and source is better than
> manual...
Nope, I have to understand the code. A manual explains the error condition
and possible fixes.
> > P.S.: I have a strange behaviour that seems to belong to masquerating.
> > When I put up a point-to-point-device, I cannot ping anyone over an
> > ethernet-device iff (if and only if) I haven't pinged him before. Iff I
> > define my ISDN-device to be 'normal' (not p-t-p), everything works fine.
> > Kernels are 2.0.x.
>
> arp problems?
How can I check/fix it?
Kurt
-------------------------------------------------------------
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