i18n for kernel 2.7.x?

i18n for kernel 2.7.x?

[Xan]

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)?

I think that internationalization is a remarkable thing of a kernel of
any operating system. It makes the kernel project more international
(in the sense that there is no privileged language) and make that more
people feel envolved in this (because these people see the kernel less far
than before, because it "speaks" their language). And (perhaps indirectly)
it makes that more people detect more bugs: if I'm a newbee and I see
"This is a bug [...] EIP: ....", in normal circumstances (and more if I
don't know english), I don't know what can I do [If the kernel "says" the
bug in rumanian for example, then I know that is a kernel bug and, maybe,
I say it to my friend that know english...]

I believe that it could be done in the future releases of kernel (I don't
believe that it could be done in the present series (2.6) because I
believe that it implies a little bit of work!).

I'm not a kernel guru so I don't know what is necessary to do for i18n of
the kernel, but I think that it's necessary to do:

1) Make a module, M, for display all the message that now kernel displays
directly. So the core of the kernel and all the other modules send the
message to display to M and then M displays this message in the selected
language (selected in the compilation of kernel). The default language
were english as now, for example, because the kernel developers are
majorty of english speakers.

2) Translate the documentation. That is,
	a) Documentation/ directory of the kernel
	b) README file and other ./ files (as COPYRIGHT...)
		Optionally, we could say in the translated files that the "official"
		translate is the english translate (for legal purposes...)
	c) Translate the web page of the kernel (www.kernel.org) for that we
	could display the language that we selected in this page (as
	www.debian.org do).


This is all what I want to communicate to you and I _hope_ that you like
it.

Regards and happy new year,
Xan.

PS: Please don't email-me. Discusion about it in group. Thanks.

Re: i18n for kernel 2.7.x?

[Tomas Szepe]

On Dec-31 2003, Wed, 13:32 +0100
Xan <DXpublica@telefonica.net> wrote:

> 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)?

Not again, please.  Read the lkml archives.  This is not going to happen.

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: i18n for kernel 2.7.x?

[Matthias Schniedermeyer]

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



Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

Re: i18n for kernel 2.7.x?

[Xan]

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

Re: i18n for kernel 2.7.x?

[Matthias Schniedermeyer]

On Wed, Dec 31, 2003 at 04:25:24PM +0100, Xan wrote:
> 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.

I'm not a kernel developer so i don't "panic". But this discussions
comes up about every half a year and i know the outcome from the past.
-> forget it.

And btw. None of your points are "new(tm)" (including the part i striped
in this mail) and all have be discussed (to death) in the past.
The outcome was always:
not practical and/or too much hassle for the developers and/or unmaintainable



Btw2:
"Those who fail to learn history are doomed to repeat it; those who fail
to learn history correctly -- why, they are simply doomed."
(Andromeda (TV-Series), Season 1.3)



Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

Re: i18n for kernel 2.7.x?

[John Bradford]

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

It is not a tabu topic at all, but as with all FAQs, unless you have
solutions to the problems which have already been raised, there is
little point in discussing them again.  Read through the archives, and
you will find responses to almost all of the points you mentioned.

John.

Re: i18n for kernel 2.7.x?

[Xan]

Dimecres 31 Desembre 2003 17:04, en/na John Bradford (<John Bradford 
<john@grabjohn.com>>) va escriure:

> > > > 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.
>
> It is not a tabu topic at all, but as with all FAQs, unless you have
> solutions to the problems which have already been raised, there is
> little point in discussing them again.  Read through the archives, and
> you will find responses to almost all of the points you mentioned.
>
> John.

Well... if (all of) you think that.... 
But, what happens with Documentation/ directory and README, COPYRIGHT, ... and 
WEB PAGE of the kernel?

It's NOT so technically hard to do. Why not so?

Re: i18n for kernel 2.7.x?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

On Fri, 02 Jan 2004 01:53:58 +0100, Xan said:

> Well... if (all of) you think that.... 
> But, what happens with Documentation/ directory and README, COPYRIGHT, ... and 
> WEB PAGE of the kernel?
> 
> It's NOT so technically hard to do. Why not so?

Oh, give me a <bleep>ing break, already.

We demonstrably have *enough* trouble keeping the English-only contents of the
Documentation/ directory in sync with the source.  What do you propose to do if/
when some kernel change requires a document update, and we can't find somebody
who is qualified to translate to Swahili, or one of the Baltic languages(*),
and so on? Pretty soon, you have 15 or 20 slowly diverging versions due to
missed updates and the like.

As far as translating the COPYING file, I think you need to see what the FSF
thinks of translating the GPL into other languages:

http://www.fsf.org/licenses/licenses.html

(Bottom line - English is canonical, and the others are basically considered
study aids for the English-challenged).

(*) Don't look at me - although I went bughunting in the cpufreq code, and have
more relatives in Riga than I do in the US, and my Latvian is quite sufficient
to deal with a newspaper, dinner conversation, or television programming, I'd
hate to be the guy trying to understand my attempt to explain the cpufreq code
in Latvian.. ;) 


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: i18n for kernel 2.7.x?

[Toplica Tanasković]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Xan wrote:
> Dimecres 31 Desembre 2003 17:04, en/na John Bradford (<John Bradford
>
> <john@grabjohn.com>>) va escriure:
> > > > > 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.
> >
> > It is not a tabu topic at all, but as with all FAQs, unless you have
> > solutions to the problems which have already been raised, there is
> > little point in discussing them again.  Read through the archives, and
> > you will find responses to almost all of the points you mentioned.
> >
> > John.
>
> Well... if (all of) you think that....
> But, what happens with Documentation/ directory and README, COPYRIGHT, ...
> and WEB PAGE of the kernel?
>
> It's NOT so technically hard to do. Why not so?

	Agreed. KDE end GNOME knowledge can be used for help if needed...
- -- 
Regards,
Toplica Tanaskovic
Coordinator of Serbian KDE Translation Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/9NuotKJqksC6c0sRAjpLAKC1RxgvZM8RjjUZ8ixHoLPoBY/WkACeJupf
Vv+DUI8Vrg3ZXlBPgdzxN7k=
=SzUP
-----END PGP SIGNATURE-----

Re: i18n for kernel 2.7.x?

[Diego Calleja]

El Fri, 2 Jan 2004 01:53:58 +0100 Xan <DXpublica@telefonica.net> escribió:

> 
> Well... if (all of) you think that.... 
> But, what happens with Documentation/ directory and README, COPYRIGHT, ... and 
> WEB PAGE of the kernel?
> 
> It's NOT so technically hard to do. Why not so?

People are already doing this for the help entries of the configure process:
http://es.tldp.org/NuLies/web/index.html (in Spanish). This is just a patch
over the kernel. The 2.6 split of the configure files will help to coordinate
the efforts, it'd not be very difficult to include it as a "extra" package
in normal distributions. It's not complete of course...