At a time when many companies are rushing to internationalize their products and
\nservices to appeal to the broadest possible market, the Linux kernel is
\nactively resisting that trend, although it already has taken over the
\nbroadest possible market\u2014the infrastructure of the entire world.<\/p>\n
David Howells recently created some sample code for a new kernel library,
\nwith some complex English-language error messages that were generated from
\nseveral sources within the code. Pavel Machek objected that it would be
\ndifficult to automate any sort of translations for those messages, and that
\nit would be preferable simply to output an error code and let something in
\nuserspace interpret the error at its leisure and translate it if needed.<\/p>\n
In this case, however, the possible number of errors was truly vast, based
\non a variety of possible variables. David argued that representing each and
\nevery one with a single error code would use a prohibitively large number of
\nerror codes.<\/p>\n
Ordinarily, I might expect Pavel to be on the winning side of this debate,
\nwith Linus Torvalds or some other top developer insisting that support for
\ninternationalization was necessary in order to give the best and most useful
\npossible experience to all users.<\/p>\n
However, Linus had a very different take on the situation:<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
[…]<\/p>\n
There are places where localization is a good idea. The kernel is *not* one of those places.<\/p><\/blockquote>\n
He added later:<\/p>\n
I really think the best option is “Ignore the problem”. The system calls
\nwill 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.<\/p>\nThat 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.<\/p><\/blockquote>\n
Pavel still felt that, since David’s code was all new, there was no ancient
\ncruft standing in the way of implementing internationalization in this one
\nnew area. He agreed there was no point in a lot of other cases, but for this
\none, it felt like being given a fresh chance.<\/p>\nBut Linus said, “Really. No translation. No design for translation. It’s a
\nnasty nasty rat-hole, and it’s a pain for everybody.”<\/p>\nHe added, “the fact is, I want simple English interfaces. And people who
\nhave issues with that should just not use them. End of story. Use the
\nexisting error numbers if you want internationalization, and live with the
\nfact that you only get the very limited error number. It’s really that
\nsimple.”<\/p>\nThe discussion ended shortly thereafter. It’s a fascinating rejection of a
\nvery politically popular attitude, based on the technical consideration that
\nkeeping the programming interface simple is worth more than keeping the user interface friendly.<\/p>\n