At a time when many companies are rushing to internationalize their products and
services to appeal to the broadest possible market, the Linux kernel is
actively resisting that trend, although it already has taken over the
broadest possible market—the infrastructure of the entire world.
David Howells recently created some sample code for a new kernel library,
with some complex English-language error messages that were generated from
several sources within the code. Pavel Machek objected that it would be
difficult to automate any sort of translations for those messages, and that
it would be preferable simply to output an error code and let something in
userspace interpret the error at its leisure and translate it if needed.
In this case, however, the possible number of errors was truly vast, based
on a variety of possible variables. David argued that representing each and
every one with a single error code would use a prohibitively large number of
error codes.
Ordinarily, I might expect Pavel to be on the winning side of this debate,
with Linus Torvalds or some other top developer insisting that support for
internationalization was necessary in order to give the best and most useful
possible experience to all users.
However, Linus had a very different take on the situation:
We don’t internationalize kernel strings. We never have. Yes, some people tried to do some database of kernel messages for translation purposes, but I absolutely refused to make that part of the development process. It’s a pain.
For some GUI project, internationalization might be a big deal, and it might be “TheRule(tm)”. For the kernel, not so much. We care about the technology, not the language.
So we’ll continue to give error numbers for “an error happened”. And if/when people need more information about just what _triggered_ that error, they are as English-language strings. You can quote them and google them without having to understand them. That’s just how things work.
[…]
There are places where localization is a good idea. The kernel is *not* one of those places.
He added later:
I really think the best option is “Ignore the problem”. The system calls
will still continue to report the basic error numbers (EINVAL etc), and the extended error strings will be just that: extended error strings. Ignore them if you can’t understand them.That said, people have wanted these kinds of extended error descriptors forever, and the reason we haven’t added them is that it generally is more pain than it is necessarily worth.
Pavel still felt that, since David’s code was all new, there was no ancient
cruft standing in the way of implementing internationalization in this one
new area. He agreed there was no point in a lot of other cases, but for this
one, it felt like being given a fresh chance.
But Linus said, “Really. No translation. No design for translation. It’s a
nasty nasty rat-hole, and it’s a pain for everybody.”
He added, “the fact is, I want simple English interfaces. And people who
have issues with that should just not use them. End of story. Use the
existing error numbers if you want internationalization, and live with the
fact that you only get the very limited error number. It’s really that
simple.”
The discussion ended shortly thereafter. It’s a fascinating rejection of a
very politically popular attitude, based on the technical consideration that
keeping the programming interface simple is worth more than keeping the user interface friendly.