lkml.org 
[lkml]   [1997]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Jive -> Kernel (International Linux)
On Wed, 15 Jan 1997, Adam D. Bradley wrote:

> > Rather than some pigin English what about French, German, Finnish, etc etc ?
> >
> > Ok, so Jive could be added too. :-)
> >
> > This would definitly have to be a compile time feature arranged so that it
> > doesn't cost any extra code/data space in the kernel, it may make Linux
> > the first truly international Unix kernel. :-)
>
> This isn't a bad idea, really. We could do it as a compile thing, or
> maybe even at run-time with modules...(hmm)...
>
> For compiled-in language support:
>
> In each directory, create a file "printk_strings.h" like this:
>
> #ifndef LINUX_LANGUAGE
> #define LINUX_LANGUAGE_ENGLISH
> #endif
> #ifdef LINUX_LANGUAGE_ENGLISH
> #define FD_DISK_CHANGE_DETECTED "Disk Change Detected"
> #define FD_DISK_SCREWED "Your Disk is Screwed"
> /* etc etc etc */
> #elifdef LINUX_LANGUAGE_JIVE
> #define FD_DISK_CHANGE_DETECTED "Yo dis be diff'd"
> #define FD_DISK_SCREWED "Yo disk be like yo mama!"
> /* etc etc etc */
> #endif
>
> And use the defined constants in printk()'s instead of literal text.

Hrm. Actually, this is a _very_ good idea anyways for reducing memory
space, but it has implications that make it possibly a bad idea.
Anyways, here's what WWIV BBS software did to handle these problems
(no RAM, multiple languages, etc):
We have a file called BBS.STR with 512byte (or 256byte?) entries.
Then a function like char *get_string(int x); So we'd do like
pl(get_string(1)); to print the first string out to the serial port.
Of course, this is just how WWIV did it. we'd want variable length
records. And we'd wanna have a smart parsing program to rip out strings
automagically. But the concept of putting these into a cached (to avoid
disk thrashing when you have a repeating message) file could probably solve
these problems. In WWIV, a simple cache of the most recent 100 messages or
whatever was used, though we could just as easily leave the cache up to the
file system code.
The biggest problem with this, however, is a big one...we'd need to
have the file system accessible at all times in order to get_string
successfully. Sure, we could preserve certain special files (like
filesystem and boot stuff) to tell the parser not to do any replacements,
but we still get a lot of complexity from this. And maintaining a database
such as the string database would be a really big pain, though not nearly as
bad as I managed to make my WWIV database.

Greg Alexander
http://www.cia-g.com/~sietch/


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