i18n for kernel 2.7.x?

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.

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

Tomas Szepe <[email protected]>

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.

Dimecres 31 Desembre 2003 13:51, en/na Matthias Schniedermeyer (<Matthias Schniedermeyer <[email protected]>>) va escriure:

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.

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.

Dimecres 31 Desembre 2003 17:04, en/na John Bradford (<John Bradford <[email protected]>>) va escriure:

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

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

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

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

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.