Messages in this thread | | | Date | Wed, 02 Dec 1998 08:39:28 -0800 | From | Bruce Korb <> | Subject | Re: 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/
| |