应该针对开发者的异常消息进行本地化吗？

我指的是显示开发人员错误地使用API的异常消息。例如错误地将null传递给方法。因此，开发人员在第一次运行错误代码时会遇到的异常类型。应该永远不会显示给系统用户的异常消息的类型。应该针对开发者的异常消息进行本地化吗？

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

http://www.codinghorror.com/blog/archives/001248.html（请没有这种理论在这里讨论）

是的，我知道，在.NET Framework遵循“本地化一切”的做法。

来源

2009-05-30 Simon

我相信，对于英国人和美国人的消息应该本地化：Ь – 2014-10-02 12:23:46

您的问题可以改为“应该所有的开发者都得到相同的错误信息，以便他们可以谷歌吗？” ;）

答案是肯定的。

翻译意味着

的消息不再相同谁写预期API。它可能具有相同的含义，或者它可能在翻译中丢失了某些东西。它可能翻译不好，在某些情况下，它可能是完全不可读的。
阅读它的人不能简单地将错误输入到Google中，并查看其他所有发生此错误的人。因为其他人都以不同的语言出现同样的错误。

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

来源

2009-05-30 12:15:10 jalf

其实jal不是我所问的。我纯粹是从让开发人员了解他们做错了什么的角度思考问题。但这是我没有考虑过的一个很好的观点。 +1 – Simon 2009-05-30 12:29:38

@jalf，我认为这就是为什么每个IBM产品都有消息编号（例如DRL0122I）的原因，尽管错误文本本身可能是本地化的。无论语言如何，您始终可以搜索消息编号。 – paxdiablo 2009-05-30 12:58:22

@Pax：真的，很好。这解决了一半的问题（让人们可以谷歌），但不是关于实际理解错误的部分。除非原始开发者能够流利地使用目标语言，否则您的翻译不太可能是完美的。 – jalf 2009-05-30 13:11:43

这一切都取决于谁将维护代码。如果开发者永远是英语的话，那么把所有的英语都保存下来是有道理的。此外，我不确定.NET Framework是否以本地方式抛出其错误消息。我一直认为这些错误信息总是以英文显示，因此将内部错误信息保留为英文也是有意义的。

来源

2009-05-30 11:53:08

从NullReferenceException异常的构造公众的NullReferenceException（）：基地（Environment.GetResourceString（“Arg_NullReferenceException”））和这里有人询问如何转关闭异常本地化 http://stackoverflow.com/questions/721337/forcing-english-language-exceptions-in-net-framework – Simon 2009-05-30 11:57:54

不，我不认为他们应该（或者至少我们不这样做，而且我们很大:-)。有足够的精力将用户所看到的所有内容本地化，而不必担心开发人员。

没有支持外文关键字和标准库的主流语言，所以对于英语的基本命令已经是开发者的先决条件。

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

来源

2009-05-30 11:53:21 paxdiablo

在我们公司，我们允许为我们的编译器/ IDE翻译异常/错误消息，并提供翻译这些异常/错误消息的框架，但我们不会自己做翻译。然后，如果他愿意，则由客户来翻译。有一些国家的英语不太流行，并且推广了自己的语言。因此允许翻译错误消息是有意义的。

来源

2009-05-30 12:15:48

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

来源

2009-05-30 12:29:02 Niki

应该针对开发者的异常消息进行本地化吗？

回答

相关问题