From: Xan <DXpublica@telefonica.net>
To: Matthias Schniedermeyer <ms@citd.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: i18n for kernel 2.7.x?
Date: Wed, 31 Dec 2003 16:25:24 +0100 [thread overview]
Message-ID: <200312311625.25178.DXpublica@telefonica.net> (raw)
In-Reply-To: <20031231125156.GA12588@citd.de>
Dimecres 31 Desembre 2003 13:51, en/na Matthias Schniedermeyer (<Matthias
Schniedermeyer <ms@citd.de>>) va escriure:
> On Wed, Dec 31, 2003 at 01:32:15PM +0100, Xan wrote:
> > Hi,
> >
> > Just a thing: why not internationalization of kernel. That is, why not
> > that the kernel could display error or debug messages in different
> > languages (for example)?
>
> This is a FAQ.
>
> http://www.kernel.org/pub/linux/docs/lkml/#s9-16
>
> So it should be better to end this before it begins (again).
It appears that you (kernel developers) have panic about it. Wow!. What a
contundent message!. It appears as a tabu topic.
In the link you provide me, there is the following information, but I want to
point some comments about it:
** (REG) There are several reasons why this should not be done:
** - It would bloat the kernel sources
Yes it bloat the kernel sources. It's evident as the support of new driver
will bloat. It's a redesign of a kernel in more abstract way and the majorty
of all abstraction redesign do.
I think that the key is what we will win and what we will lose with i18n of
kernel. I believe that the positive reasons have more weight.
Why not make a module that displays all the information from the kernel to the
user, shell, ....?. It not only serve us for i18n. It could serve us as low
support for Brailley's readers or any other outputs. Imagine that the kernel
is running in a virtually reality machine. It could be interesting that if a
kernel bug appears in some process, then the bug is displayed as sound, image
and feelings (the next virtually reallity machine gerneration will support
this). So there is a little work of kernel in this process of displaying
bugs. isn't?
** - It would drastically increase the cost of maintaining the kernel message
database
Not. We could have all the traductions as avaliable modules. If we want
display message in catalan, so we have to "load" the cataln module and switch
to catalan the display option of kernel. The database of messages?. If we
have the english messages in the core kernel (eventually with an identifier),
then, in some circumstances, the core kernel pass this message to module of
display, say M, then M with the help of cataln module translate literally the
english message in catalan message. I believe that M can add to the
traduction some process as: "show it as brailley" if module is avaliable.
- Kernel message output would slow down
** We will have to think what optimize the message output with the new
situation. I beleive that it's more prefered the abstraction versus a little
bit more slowly kernel.
** - English is the language in which the kernel sources are written, and thus
is the language in which kernel messages are written. Developers cannot be
expected to provide translations
Yes, but the developers allways have the original message. We could add an id
to any message. So any "translated bug" that we send to any developer has its
id and so the devenloper could see the message in the id-message table.
And it's clear that the developers will not translate nothing. Sure there will
be other people that would translate mesages.
*** - Bug reports should be submitted in English, and that includes kernel
messages. If kernel messages were to be output in some other language, most
developers could not help in fixing bugs
*** - Translation can be performed in user-space, there is no need to change
the kernel
---> How?
- It would bloat the kernel sources
Finally, it will not be done. No core developer supports this. Neither does
Linus. Don't even ask.
And the internationalization of the Documentation directory, README,... files
and the web page?
Regards,
Xan.
>
>
>
> Bis denn
next prev parent reply other threads:[~2003-12-31 15:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-31 12:32 i18n for kernel 2.7.x? Xan
2003-12-31 12:45 ` Tomas Szepe
2003-12-31 12:51 ` Matthias Schniedermeyer
2003-12-31 15:25 ` Xan [this message]
2003-12-31 16:00 ` Matthias Schniedermeyer
2003-12-31 16:04 ` John Bradford
2004-01-02 0:53 ` Xan
2004-01-02 2:39 ` Valdis.Kletnieks
2004-01-02 2:47 ` Toplica Tanasković
2004-01-02 15:27 ` Diego Calleja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200312311625.25178.DXpublica@telefonica.net \
--to=dxpublica@telefonica.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ms@citd.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox