localization - 翻译错误信息是否“正确”？

Question

根据目标翻译语言，这在某种程度上是主观的，但请耐心等待。

我最近参与了一个翻译项目。目标是将 MVC 框架的字符串翻译成希腊语。

框架的 70% 的语言字符串被翻译，但 30% 被故意遗漏。决定是我们不会翻译针对应用程序开发人员的错误消息。

这背后的原因（简而言之）是：

面向设计师/程序员。程序员（甚至设计师 :)）应该对英语有基本的了解，至少足以让他们在不知道它的意思时可以在 Google 上搜索它。（种族主义的？）
面向开发人员，在完美的世界中不应向应用程序的最终用户显示，因为它们涉及 Web 应用程序本身的内部工作。即“您必须在数据库配置文件中设置数据库名称。”
也许最重要的是，当开发人员试图获取有关错误的更多信息/帮助时，它们会使开发人员的生活变得更加艰难。例如，上述错误在 Google 中产生 8 个结果（带引号），而其希腊语翻译结果正好为 0。

我知道这取决于目标翻译语言的流行程度和应用程序本身。例如，我猜测有大量关于德语 SAP 错误消息的文档（我知道，我知道，SAP 是德语，但你明白了），而不是关于随机应用程序 X 的希腊错误消息文档全球安装约 500 台。

总结一下：当您为您的应用程序开发语言翻译包时，您是否翻译错误消息？你只为英语/西班牙语/德语/法语等主要语言做吗？还是你让它们完好无损？我不是在寻找“正确”或“正确”的答案，而是在寻找“最佳实践”的答案，或者这个问题是否在您经历过的任何“官方”标准/政策中定义。

score 21 · Accepted Answer

一个包含内置错误消息的好的框架应该有一个 i18n 选项。这对用户来说非常重要。

另一方面，不得翻译异常消息。你已经指出了一个重要的原因——搜索。是的，它们适用于开发人员，而不是最终用户。

如果异常消息也用作向用户显示的消息，这是错误的设计。异常可能包含 i18n 键。

score 10 · Accepted Answer

无论是否翻译，请确保始终使用唯一 ID 并允许用户复制它。

提示：在某些应用程序中，按 Ctrl+C 会复制消息而不是可编辑的，这样可以很好地实现相同的隐藏功能。

score 4 · Accepted Answer

我只能提供我自己的意见，但对于我作为一名德国开发人员来说，收到翻译的错误消息总是很烦人，尤其是对于广泛传播的软件，例如 MS 软件。这有两个原因：

德语错误消息通常更难理解，因为德语使一切听起来更复杂。此外，与 IT 相关的词通常没有好的翻译。德国开发者要么不得不使用英文单词，要么用繁琐的直译代替它们。顺便说一句，MSDN 网站也是如此。
此外，正如您已经提到的，在英文网站上使用 google 找到这些错误的解决方案变得更加困难。德国开发者社区比英语社区小得多...

score 3 · Accepted Answer

如果该应用程序是针对普通企业或消费者用户的，并且向他们显示错误消息以便他们可以理解或采取一些行动，那么我认为应该对其进行翻译。如果错误消息纯粹是为了记录和故障排除，那么翻译应该是不必要的。

score 2 · Accepted Answer

用两种语言打印它们怎么样？用户/本地管理员知道发生了什么，可以搜索它并与开发人员沟通。

score 2 · Accepted Answer

不要翻译异常消息；它可能会变成翻译的噩梦。

我经常使用 Microsoft Office 自动化。翻译成希伯来语的异常信息让我很难过：

他们中的大多数我在 Google/MSDN 上找不到，所以我必须自己将它们翻译回英文，以便在谷歌上搜索。
其中一些通过翻译的类名来引用对象。我（作为程序员）操作的对象类总是用英文命名。这只会使消息难以理解。
其中一些是格式化的字符串，其中消息本身被翻译但构造消息的参数不是；这使得消息更难以理解，有时这意味着消息无法在默认的 MsgBox 中正确显示（从右到左的语言可能是一场噩梦）。

根据我的经验，开发人员需要他的 Exception 消息是英文的，因此翻译这些消息只需要双方付出更多的努力，而且不会给你带来太多好处。

score 0 · Accepted Answer

通常有很多错误消息，并且它们通常只是偶尔显示。因此，翻译它们有时似乎太费力了。

score 0 · Accepted Answer

取决于应用程序。一个高度技术性的应用程序，将由懂英语和目标语言的人使用，您可能会对英语错误消息感到满意。

如果它是最终用户可以看到的消息，则应进行翻译。想一想，如果您使用的是由日本开发人员编写的应用程序，您会看到一条日语错误消息。这可能对你没有那么大的帮助——你不知道它说了什么，你是否可以做任何事情。

8 回答 8