kernel support for non-English user messages

Maybe for developers, but users like it. I can still remember back in
the Old Days, taking those error codes and looking them up in something called a "manual" where there was a coherent explanation of what had gone wrong and even suggestions on what to do about it.

(Of course there were drawbacks, too... when the leather belt driving
the Difference Engine broke, for example, it was every man for himself!)

--
Chuck

Well, you don't need error codes to make a comprehensive manual, you can just look up the English error message, and get a detailed explaination of it, in any language.

John.

Can someone hand that man a japanese error message and ask him to look it up in a japanese dictionary?

Walk for a moment in the other language's shoes...

Mixing metaphores as time flies....

gerrit

The Japanese are taught to read and write English as school children. They also are taught how to write their own language in Romanji, which is an adaptation of the Roman alphabet. How much you want to bet that the Japanese use English when they write error messages? While I understand the spirit of your statement, despite its technical error, the spirit of my response is that you could replace "Japanese" with any other language and get the same effect.

Linus Torvalds isn't the first Finn I've encountered who speaks, reads, and writes English impeccably.

I've also never met a German who didn't speak English.

When we have Asian vendors from various countries come visit where I work, even the ones who need a translator speak English better than we speak their language.

The point of this painfully off-topic rant is that messages being written in English are a disadvantage for no one since they all already know English. The messages are also simple enough that anyone intelligent enough to care what a Linux kernel message MEANS is probably intelligent enough to at least have an English-to-Whatever dictionary on hand.

I personally have a list of every kernel message I could extract from the source code of 2.4.20, and I've examined a lot of them. It's a lot like reading Dr. Seuss. Although some of the words are long, the vocabulary is incredibly small. A lot of text is abbreviations and acronyms that you wouldn't translate anyhow!

This isn't an issue of fairness to people who speak other languages. It's simply unnecessary and costs us far more than we gain. One of the things I like about the Linux kernel is that people strive to "do the right thing", and it's improving all the time. Internationalizing kernel messages, that shouldn't appear anyhow if we did our jobs right, would NOT be an improvement.

Mind you, I like to try to be open-minded. Based on my own reasoning, I see this as being unnecessary, but I can be convinced otherwise. You're just going to have to come up with a much better reason than what has been offered by yourself and others in this thread.

Thats a hopeless simplification for non techies and for some techies.

I would be interested in how you extracted them, since a tool that can do this is the relevant 99% of the discussion, whether its for building message explanations, translation, reducing messages for embedded...

I recognize that having internationalized messages would be an advantage. The question is whether or not that advantage outweighs the disadvantage.

This shouldn't stop anyone from working on it, however. My message compression work only shaves off about 64k, MAYBE, which compared to the rest of the kernel footprint is tiny. What you get is a more complex printk, no lower-case letters, and a meager space savings. Embedded users might like it, but they'll start out with less text to compress in the first place; those who stand to benefit the most are the ones who can benefit the least. Oh, and the build process will take at least twice as long. IF this can be implemented in a way that makes it entirely transparent, maybe a few people will use it, so my primary motivation for doing it is that I'm enjoying working on it. :)

I used 2.4.20. I modified Rules.make. The line which does the compile (line 60), I changed like this:

%.o: %.c
$(CPP) $(CFLAGS) $(EXTRA_CFLAGS_nostdinc) -DKBUILD_BASENAME=$(subst
$(comma),_,$(subst -,_,$(*F))) $(CFLAGS_$@) $< > $<.i ; \
$(CC) $(CFLAGS) $(EXTRA_CFLAGS_nostdinc) -DKBUILD_BASENAME=$(subst
$(comma),_,$(subst -,_,$(*F))) $(CFLAGS_$@) -c -o $@ $<

When I built the kernel, for every .o file, I also got a .c.i file. I used a script to scan the tree for .i files. This is the script:

#!/bin/sh

for i in ls -A | grep .i$
do
if [ -f $i ]
then
/home/tim/tmp/prkex < $i
fi
done

for i in ls -A
do
if [ -d $i ]
then
P=pwd
cd $i
$0
cd $P
fi
done

And here's 'prkex', a horrible little extraction program that I hacked together rather abruptly. It doesn't do anything cool like use yacc or regex. It gets the printk format strings using a half-wit state machine. I figure I can get away with posting it because it's shorter than a lot of patches I see. :)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>

/* This is implemented as a state-machine which parses the input for
strings which match:
printk("...", ...);
*/

/* This is to deal with backslash followed by octal. Since I don't
try to deal with that properly, it's kinda pointless to have this. oh well. */
int state_stack[10];
int top_state = 0;

#define STATE (state_stack[top_state])

char *printk_string = "printk";
char last_out = '\n';

/* When extracting words, \n is a separator. We don't need redundant \n */ void output_char(char c)
{
if (last_out == '\n' && c == '\n') return;
last_out = c;
putchar(c);
}

/* Find printk and look for everything in the format string. Deal with
concatenation of multiple partial strings and ignore anything outside of quotes (__FILE__, etc) until we hit , or ). */
void process_char(int c)
{
switch (STATE) {
case 5: /* look for 'k' */

       if (c == printk_string[5]) {
           STATE = '(';
       } else {
           STATE = 0;
       }
       break;
   default:  /* Look for first 5 chars of 'printk' */
       if (STATE < 5) {
           if (c == printk_string[STATE]) {
               STATE++;
           } else {
               STATE = 0;
           }
       } else {
           STATE = 0;
       }
       break;
   case '(':  /* Look for ( */
       if (isspace(c)) return;
       if (c == '(') {
           STATE = '[';
       } else {
           STATE = 0;
       }
       break;
   case '[':  /* Look for " */
       if (isspace(c)) return;
       switch (c) {
       case 34:
           STATE = 34;
           break;
       case ')':
       case ',':
       case ';':
           output_char('\n');
           STATE = 0;
           break;
       default:
           /* default doesn't abort because we get __FILE__, etc. */
           output_char('\n');
           break;
       }
       break;
   case 34:    /* We're in a string */
       if (c == '\\') {
           top_state++;
           STATE = '\\';
           return;
       }
       if (c == 34) {
           STATE = '[';
           return;
       }
       output_char(c);
       break;
   case '\\':  /* partially deal with backslash. */
       if (state_stack[top_state-1] == 34) {
           switch (c) {
           case 'n':
               output_char('\n');
               break;
           case 't':
               output_char('\t');
               break;
           case '\n':
               break;
           default:
               output_char(c);
               break;
           }
       }
       top_state--;
       break;

}
}

int main(int argc, char *argv[])
{
int c;

   state_stack[0] = 0;
  
   while (!feof(stdin)) {
       c = getchar();
       if (c != EOF) process_char(c);
   }

return 0;
}

Suggestion: Chop your CCs. I sus pect Linus gave up on this topic a long time ago, as (most likely) have the majority of the others.

No, they're not (taught to write Japanese in Romaji, that is).

Well, it rather depends on the person... try setting your locale to ja_JP.eucJP, and you might be surprised by the applications that give you Japanese messages. Certainly, some Japanese people prefer messages in English, but that can hardly be generalized across the entire userbase.

My only answer is, you have only had the opportunity to meet people from overseas who have some English ability... really, your argument is on the same level as "I've got lots of foreign friends who all like <whatever>, so all foreigners must like <whatever>."

Bruce

PS: I'm against translating kernel messages, but for technical reasons (simple == good) rather than some wild idea that everybody else in the world can understand English.

Perhaps I was mistaken on that.

Applications. Far more people work on applications than on the kernel.

I'm not saying I don't think Japanese would benefit from Japanese messages. I'm saying that, in my humble estimation, i18n kernel messages would lose in the cost-benefit analysis.

You make a good point.

I agree that an objective technical analysis, not personal opinion, should be the basis of our decision on this matter.

Just to clarify, by 'applications' I meant things like make and gcc ;)

[SNIPPED...]

You think you are kidding? The main hard disk on one of our VAX/11-750 was belt-driven. I think it was a RA50?? Anyway, it consisted of a 55 pound sealed aluminum casting with fins (HDA), that a technician would roll in using a refrigerator dolly. It had a pulley on it's bottom that was fit into a belt to spin it up. The motor sounded like a vacuum-cleaner motor, probably made by Hoover.

Wmmm.

$ ls /  # "DIR"
%DIRECT-W-NOFILES, no files found

Remember versioned files? What would Unix do with....

$ renam *.*;* *.*;1

$ ls
  *.*;1
$
You get left with one file called *.*;1  -- nice!

I did like....

$ set proc/priv=all
$ @sys$system:shutdown

It was almost as amazing as init 0 on Red-Hat distributions....

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

Before that last thing, you had me really worried for a while. I thought you might be seriously in need of some mental evaluation when you claimed that users "liked looking up error numbers in manuals".

Whee. April first is long gone, but the jokers stay around.

Linus

[email protected] (Chuck Ebbert) wrote on 11.04.03 in <[email protected]>:

I think that's the real point here: without a manual to look things up in, none of this actually buys us anything.

The grepme file someone proposed seems to be a reasonable first step, starting to number or otherways add a code to everything doesn't - it may or may not be a reasonable thing after there is experience with the grepme file, but we don't have that experience right now so we don't know.

Oh, yes: one thing *might* make sense: have a script to extract kernel messages, and have source conventions to support that script, such as:
* when a message is built with more than one statement, some way to figure out where it starts and ends.
* a way to attach a comment that can be extracted by that script as an explanation of the message.

(Which makes me think it might be a nice gcc extension (in general, not necessarily for the above thing - actually, probably not for that, so take this as an unrelated aside) to have function-relative line numbers available as some sort of symbol. __FUNCTION__ (or __PRETTY_FUNCTION__) together with that (and possibly __FILE__) would make a semi-stable identifier - it only changes when that function is changed, as opposd to when anything is changed that happens to be before that function in the same source. Of course, many variations of that idea are imaginable.)

MfG Kai

Agreed.

It was me. I'm happy to maintain it, if there is sufficient interest.

Agreed.

John.