我指的是显示开发人员错误使用 API 的异常消息。例如，错误地将 null 传递给方法。因此，开发人员第一次运行错误代码时会遇到的异常类型。永远不应该向系统用户显示的异常消息类型。
这与以下理论有关：由于编程语言是英语，因此程序员已经了解英语。或者至少足以破译异常消息。
http://www.codinghorror.com/blog/archives/001248.html（请不要在这里讨论这个理论）
是的，我知道 .net 框架遵循“本地化一切”方法。
您的问题可以改写为“所有开发人员都应该收到相同的错误消息，以便他们可以通过 Google 搜索吗？” ;)
答案是肯定的。
翻译过来的意思是
关于 .NET 的“本地化一切”方法，这是可怕的。我被它绊倒了无数次，特别是因为如果它无法找到本地化资源，它确实不给你简单的英文版本。相反，它会给您一个“无法找到资源”错误，从而有效地丢弃实际的错误信息。
不，我认为他们不应该这样做（或者至少我们不这样做，而且我们相当大:-)。我们付出了足够的努力来本地化用户看到的所有内容，而不必担心开发人员。
目前还没有支持外语关键字和标准库的主流语言，因此对英语的基本掌握已经是开发人员的先决条件。
当然，如果开发人员开发自己的库（或语言），他们可以非常自由地本地化或选择非英语语言。
在我们公司，我们允许为我们的编译器/IDE 翻译异常/错误消息，并提供翻译这些异常/错误消息的框架，但我们自己不进行翻译。然后由客户决定是否愿意翻译。有许多国家的英语并不那么流行，但他们自己的语言得到了推广。因此，允许翻译错误消息是有意义的。
这完全取决于谁来维护代码。如果开发人员始终是英语，那么将其全部保留为英语是有意义的。
此外，我不确定 .NET Framework 是否以本地化方式抛出错误消息。我一直认为这些错误消息始终是英文的，因此将内部错误消息也保留为英文是有意义的。
如果您翻译异常消息，那么您还应该翻译出现异常消息的所有文本。这包括您拥有的任何知识库或错误跟踪系统，因为用户和程序员会希望在其中搜索他们在屏幕上看到的异常消息。