Messages in this thread | | | Date | Wed, 15 Jan 1997 15:20:57 -0500 (EST) | From | Greg Alexander <> | Subject | Re: 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/
| |