lkml.org 
[lkml]   [1998]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Internationalizing Linux
John R. Lenton wrote:
>
> Hello all.
>
> I've been thinking of ways in which I could help Linux while
> trying to learn C, and have come back to an item that bugs
> me every so often: Support for different languages. Would it
> be a Good Thing to be able to choose the language Linux
> speaks? I'm thinking along the lines of replacing e.g.
> printk("Calibrating delay loop...") with
> printk(CALIBRATING_DELAY_LOOP) and then including a
> language-specific .h file with all the #define's. I

This causes a maintenance headache. With this scheme,
whenever a new printk gets a macro-ized, you will have
to make sure the entries are correctly added to the 'n'
language specific headers, even if they are inserted in English.
Also note, there are som 20+ thousand (if my source is correct,
because I have not counted myself) printk's.

Not to worry.

I have a set of programs that will fix this. Automagically.
It will replace every 'printk()' and 'panic()' call with
a macro and a stylized comment. A second program can then
be run against this modified source and, using a file of
optional alternate format strings, produce a header file with
definitions for the inserted macros. No work. No sweat.
All 20+ thousand printk's replaced in a few minutes.

After that comes more interesting stuff.

Once the comment-to-header extraction stuff is in place,
then we can infect it with interesting featuritis:)

1. some printk's can be selectively compiled out
2. some printk's can be selected out based on
fcntl'ed threshholds
3. (longer term) the kernel-based formatter can be
generally confined to panics. Most other printk's (events)
are inserted into the circular log as event codes.
A user land display program finds the format string
based on the event code. Benefits:
a) Reduced locked memory for kernel strings
b) Reduced locked memory for the log buffer
c) Reduced latency for interrupt level events
This in no way eliminates the need for an in-kernel
printk function. add-on drivers will need it.
Non-panic printk's would become special string events.

> and an argentine-spanish .h

If I send you a file with the extracted format strings,
could you translate that? At least a little bit.
With that much done, we would have a clear demonstration
project. I could do a rusty-mexican-spanish.h, but
I think argentine-spanish is better ;-)

> This would be very nice if the openbios project works out,
> because then Linux could start up using non-ASCII fonts,
> couldn't it not? And even writing right-to-left. The problem
> is that some of the more esoteric languages out there would
> have a grammar so twisted [1] that you couldn't get around
> things like printk("Holy %s, your %s has gone
> %s!",cow,wife,crazy) that easily. We could always create
> newspeak, or something.

If you have to reorder parameters, you can always reorder them
with the "%2$s" construct in user-land printf's.

> My question is, then:
> o Is this idea a Good Idea?
> o What am I overlooking?

I can get you the extracted English format strings in a couple
of days, but I would hold off doing very much work until
there is some moderate interest in considering it.

--
Bruce Korb | Data Design Systems, Inc.
Korb at DataDesign dot com | 45 Cabot Dr., Suite 110
Voice: 408-260-0280 | Santa Clara, CA 95051
Fax: 408-260-0281 | USA

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.607 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site