异常信息应该全球化吗？

Question

我正在开展一个项目，开始做全球化应用所需的一切工作。其中一个经常出现的问题是是否要将异常消息进行全球化，但是需要确保string.Format使用的是CultureInfo.CurrentCulture而不是CultureInfo.InvariantCulture。此外，这意味着异常消息将存储在可以标记为与特定文化相关的资源文件中。

那么问题是，异常消息应该全球化还是应该保留InvariantCulture或作者所在国家/地区（在我的情况下为en-US）？

- Orion Adrian

Answer 1

异常消息很少直接显示给用户。您需要针对每个字符串考虑消费者。显然，用户界面中的文本需要国际化，但如果异常消息仅将被支持人员看到（或者当用户点击按钮后将可见并通过电子邮件发送给支持人员），那么翻译它有什么好处呢？

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

微软国际化自己的异常消息是有道理的，因为来自全世界的开发人员都会阅读这些消息 - 但除非您是在多个国家拥有开发人员且他们不共享共同语言的跨国公司，否则我不会翻译那些真正面向开发/支持的消息。

- Jon Skeet

---

@Theraot：这是你的选择 - 就我个人而言，我不会为Noda Time这样做，但这真的取决于你。 - Jon Skeet

@JonSkeet 全球化异常消息似乎会引起麻烦：https://dev59.com/Y3VC5IYBdhLWcg3wsTfv 所以我会使用英语和连接（为了避免 CA1305，我更喜欢在可以的情况下避免抑制）。此外 +1。 - Theraot

@JonSkeet那么你如何将异常设置为仅记录一种语言？如果从框架中获得了意外的结果，则应进行本地化。意外情况应该记录在日志中，以便有人可以查看发生了什么。由于.NET使用CultureInfo（或其他内部机制？），因此在日志中获取俄语或中文内容可能会出现问题，即使设置了CultureInfo和UIInfo，某些消息似乎也会以系统语言显示。那么你如何让支持更轻松？ - Offler

@Offler：这确实很棘手。我想异常是在抛出时本地化而不是记录时，这很烦人。我猜一种方法是将线程的当前文化设置为“您希望阅读日志的任何文化”，并确保您在任何要在用户文化中使用的地方明确指定文化。但这可能会导致其他问题，具体取决于您正在编写的应用程序类型。说实话，这一切都很混乱。它应该被设计为存储消息ID和参数，以便可以在任何文化中呈现异常。 - Jon Skeet

@Jonskeet "我猜一种方法是将线程的当前区域设置为“您乐意阅读日志的任何语言环境”" - 不行，对于所有异常都不适用。我尝试了一下，得到了两种不同语言混合的结果（似乎取决于异常类型）。例如：我会收到英文的FileException异常和德文的SocketExceptions异常。 - Offler

Answer 2

通常来说，我不这样做。

对于可能被用户看到的字符串进行全球化处理，同时避免异常消息向UI层冒泡，是正确的做法，对吧？

对吧？ :)

- Greg D

Answer 3

如果你将要处理异常，那么要么保留它们的语言为你所理解的语言，要么给它们编码以便你可以在本地语言中查找。

- StingyJack

Answer 4

我猜你所说的全球化，指的是符合i18n标准，通常称为国际化。是的，需要对GUI的所有可见部分进行国际化，包括诊断信息。但日志文件不应该国际化，因为开发人员需要在其中获取真正的信息，例如堆栈跟踪。

- Glenn

---

在 .Net 中，命名空间被称为“全球化”。我们被迫使用微软强加的术语。 =/ - StingyJack