在许多公司竞相将其产品和服务国际化，以吸引尽可能广泛的市场之际，Linux 内核却在积极抵制这一趋势，尽管它已经占领了最广泛的市场——整个世界的基础设施。

David Howells 最近为一个新的内核库创建了一些示例代码，其中包含一些复杂的英文错误消息，这些消息来自代码中的多个来源。Pavel Machek 反对说，为这些消息自动化任何类型的翻译将很困难，最好只是输出一个错误代码，让用户空间的某些东西随意解释错误，并在需要时进行翻译。

然而，在这种情况下，可能出现的错误数量确实非常庞大，基于各种可能的变量。David 认为，用单个错误代码表示每一个错误将使用数量过多的错误代码。

通常，我可能会认为 Pavel 会在这场辩论中获胜，Linus Torvalds 或其他一些顶级开发人员会坚持认为，为了给所有用户提供最佳和最有用的体验，国际化支持是必要的。

然而，Linus 对这种情况有非常不同的看法

我们不国际化内核字符串。我们从来没有这样做过。是的，有些人试图为翻译目的做一个内核消息数据库，但我绝对拒绝将其作为开发过程的一部分。这很麻烦。

对于一些 GUI 项目，国际化可能很重要，它可能是“TheRule(tm)”。但对于内核来说，并非如此。我们关心技术，而不是语言。

因此，我们将继续为“发生了一个错误”给出错误代码。如果/当人们需要更多关于究竟是什么_触发_了该错误的信息时，它们就是英语字符串。您可以引用它们并在谷歌上搜索它们，而无需理解它们。事情就是这样运作的。

[...]

在某些地方，本地化是个好主意。内核*不是*其中之一。

他后来补充说

我真的认为最好的选择是“忽略问题”。系统调用仍将继续报告基本错误代码（EINVAL 等），而扩展错误字符串将只是那样：扩展错误字符串。如果您无法理解它们，请忽略它们。

话虽如此，人们一直想要这些类型的扩展错误描述符，而我们没有添加它们的原因是，通常情况下，它带来的麻烦比它必要的价值更大。

Pavel 仍然认为，由于 David 的代码都是新的，因此没有任何陈旧的累赘阻碍在这个新的领域中实现国际化。他同意在许多其他情况下没有意义，但对于这种情况，感觉就像被给予了一个新的机会。

但 Linus 说：“真的。不翻译。不为翻译而设计。这是一个令人讨厌的、令人厌恶的陷阱，而且对每个人来说都很痛苦。”

他补充说：“事实是，我想要简单的英语界面。而那些对此有意见的人应该 просто 不要使用它们。故事结束。如果您想要国际化，请使用现有的错误代码，并接受您只能获得非常有限的错误代码这一事实。就这么简单。”

讨论很快结束了。这是一个对非常流行的政治态度的令人着迷的拒绝，它基于技术考虑，即保持编程接口简单比保持用户界面友好更有价值。

注意：如果您在上面被提及并且想要在评论区上方发布回复，请将包含您的回复文本的消息发送至 ljeditor@linuxjournal.com。