是否应该针对开发人员的异常消息进行本地化？

Question

我指的是显示开发人员错误使用API​​的异常消息。例如，错误地将null传递给方法。所以开发人员第一次运行错误代码时会遇到的异常类型。永远不应该向系统用户显示的异常消息类型。

这与理论有关，因为编程语言是英语的，那么程序员已经对英语有所了解。或者至少足以破译异常消息。

http://www.codinghorror.com/blog/archives/001248.html（请不要在这里讨论这个理论）

是的，我知道.net框架遵循“本地化一切”方法。

Answer 1

您的问题可以改为“如果所有开发人员都收到相同的错误消息，那么他们可以Google吗？” ;）

答案是肯定的。

翻译意味着

• 该消息不再与编写预期API的人相同。它可能具有相同的含义，或者它可能在翻译中丢失了一些东西。它可能翻译得很糟糕，在某些情况下，它可能是完全不可读的。
• 无论是谁阅读它都不能简单地将错误输入Google并查看其他所有收到此错误的人。因为其他人用不同的语言得到了同样的错误。

关于.NET的“本地化一切”方法，它太可怕了。我被无数次绊倒了，特别是因为如果它无法找到本地化资源，它会不给你简单的英文版本。它会为您提供“无法找到资源”错误，从而有效地丢弃实际的错误信息。

Answer 2

不，我不认为他们应该（或者至少我们不这样做，而且我们非常大:-)。在本地化用户看到的所有内容时都需要付出足够的努力，而不必担心开发人员。

没有主流语言支持外语关键词和标准库，所以对英语语言的基本命令已经成为开发人员的先决条件。

当然，如果开发人员开发自己的图书馆（或语言），他们可以自由地进行本地化或选择非英语语言。

Answer 3

在我们公司，我们允许为我们的编译器/ IDE翻译异常/错误消息，并提供框架来翻译这些异常/错误消息，但我们不会自己进行翻译。然后，如果他愿意，由客户进行翻译。有许多国家的英语不受欢迎，而且自己的语言得到推广。因此，允许转换的错误消息是有意义的。

Answer 4

这完全取决于谁将维护代码。如果开发人员总是英语，那么用英语保留全部是有意义的。

此外，我不确定.NET Framework是否以本地化方式抛出其错误消息。我一直认为这些错误信息总是用英语，所以用英语保留你的内部错误信息是有意义的。

Answer 5

如果您翻译异常消息，则还应翻译发生异常消息的所有文本。这包括您拥有的任何知识库或错误跟踪系统，因为用户和程序员将需要搜索他们在屏幕上看到的异常消息。