异常消息是否应该全球化答案

【问题标题】：Should Exception Messages be Globalized异常消息是否应该全球化
【发布时间】：2010-10-03 05:35:03
【问题描述】：

我正在处理一个项目，我刚刚开始做所有必要的工作以使应用程序全球化。经常出现的一件事是是否将异常消息全球化，但要确保 string.Format 使用 CultureInfo.CurrentCulture 而不是 CultureInfo.InvariantCulture。此外，这意味着异常消息将存储在可以标记为特定于文化的资源文件中。

所以问题是，异常消息应该全球化还是应该留在 InvariantCulture 或作者所在的国家？在我的情况下，美国。

【问题讨论】：

标签： c# exception globalization

【解决方案1】：

异常消息应该很少直接显示给用户。您需要考虑每个字符串的消费者。显然，用户界面中的文本片段需要国际化，但如果异常消息仅将由支持人员看到（或者将对用户可见，然后在他们单击时通过电子邮件发送给支持人员按钮）那么翻译它的好处在哪里？

如果你走得太远，你不仅会浪费时间和精力（i18n 可能需要很多的努力），而且还会让你的支持生活变得更加艰难。您真的不想阅读用外语编写的日志文件并将其翻译回您的母语。

微软将他们的异常消息国际化是有意义的，因为它们将被来自世界各地的开发人员阅读 - 但除非你是跨国公司，开发人员在多个国家没有共同语言，我不会翻译真正用于开发/支持的消息。

【讨论】：

+1 但我从前雇主那里听到的一个“原因”是，可以通过多种方法引发类似的异常。如果他们想要更改异常的措辞，他们只需要在一个地方编辑资源包。我认为这很愚蠢......
@Outlaw: 是的，这很愚蠢——因为这意味着如果您需要更改一个站点而不是另一个站点的措辞（这在我看来很可能），您还有很多工作要做.
@Jon Skeet 好的，现在如果我正在开发一个免费库，可以由来自不同国家的各种开发人员使用并且没有 UI 部分，该怎么办？全球化异常消息是否值得？即使人们会说它是重复的，是否值得提出一个单独的问题？啊……哲学太多了。
@Theraot：这是你的选择——我个人不会在野田时间这样做，但这真的取决于你。
@JonSkeet 异常消息的全球化似乎会造成麻烦：stackoverflow.com/questions/209133/… 所以我将使用英语和连接（为了避免 CA1305，我宁愿尽可能避免抑制）。还有+1

【解决方案2】：

通常情况下，我不会。

将用户可能看到的字符串全球化，并且您不会让异常消息渗透到 UI 中，对吗？

对吗？ :)

【讨论】：

【解决方案3】：

如果您要负责处理异常，请使用您可以理解的语言保留它们，或者提供代码以便您可以用您的母语查找它们。

【讨论】：

【解决方案4】：

我假设全球化，您的意思是i18n 兼容，通常称为国际化。是的，将 GUI 的所有可见部分国际化，包括诊断消息。日志文件是开发人员获取堆栈跟踪等真实信息的地方，不应进行国际化。

【讨论】：

在 .Net 中，命名空间被称为“全球化”。我们被 MS 强加的任何行话所困。 =/