Question

以下代码返回一条消息，指出输入值是否是回文：

（就本文而言，语法并不重要，或以任何特定语言编写）

function isPalindrome(
    value: string, 
    successMessage: string = "Is palindrome", 
    failureMessage: string = "Is not palindrome"): string {

    return value.reverse() == value ? successMessage : failureMessage;
}

在上面的代码中请注意，默认消息是用英语编写的，但是由于它们是作为参数提供的，因此该方法可以轻松地进行本地化，并且由于该方法具有消息的默认值，因此不会强制开发人员提供他们；例如：

isPalindrome("level") // returns "Is palindrome"

但是我们可以证明本地化；例如，西班牙语：

isPalindrome("level", "es palíndromo", "no es palíndromo") // returns "es palíndromo"

这让我开始思考，什么时候代码在设计时应考虑本地化？

另一个例子是例外。例如：

class PalindromeException : Exception("Is not a palindrome")

function validatePalindrome(value: string): void {
    if (value.reverse() != value) {
        throw PalindromeException();
    }
}

在此示例中，请注意，无法在异常中本地化消息。我知道在第一个示例中可以使用相同的原理轻松解决此问题，但它的目的是为了证明缺乏全球化。

因此，什么时候应该将全球化应用于代码，以便可以对它进行本地化？什么时候重要，什么时候不重要？

Answer 1

我相信，没有理想的答案-一切都取决于您的体系结构和用例。

但是，我建议使用以下模式：

所有日志消息（服务器和客户端）均应为英文
所有错误API响应均应始终提供英文说明和唯一的错误代码，您可以将其翻译为客户端的友好消息
为了提供良好的用户体验，所有客户端消息均应使用用户的语言

通常，以英语获取所有技术数据（日志，错误等）是一个好习惯。用户必须了解所有面向用户的数据。

Answer 2

这在很大程度上取决于您的用例。我建议立即本地化显示在前端的消息。我的经验是，稍后进行此操作非常昂贵。对于调试或监视消息，我可能只会用英语完成，因为大多数开发人员都可以阅读英语消息。

Answer 3

所有标签都需要翻译。

对于此定义，文本是最终用户读取的信息。在这种情况下，标签是一段文本，它同时不是用户输入或用户数据。

举个例子，在“另存为” 对话框中，文件名将是用户输入，即文件内容 用户数据和两个按钮上的保存和取消标签将是标签（因此需要翻译）。

鉴于此定义，规则如下：

只需翻译用户界面代码，它就会翻译所有标签。相反，不直接面对最终用户（例如库或后端服务）的业务逻辑代码根本不会翻译。此外，除了用户输入或用户数据之外，业务逻辑实现或业务逻辑 API 均不处理文本。

因此，该规则还暗示将业务逻辑代码与用户界面代码完全分开。进行测试非常方便。

以回文示例为例，该函数将为业务逻辑，并且不会返回文本，而是更合适的示例，例如布尔值或枚举。然后，用户界面代码将评估返回值并对其进行适当的翻译。例外情况也是如此。

Answer 4

应该进行本地化的唯一位置是UI。如果您坚持MVC的separation of concerns原则（或类似MVP之类的东西），那么本地化将完全发生在 View 部分。您的isPalindrome函数听起来更像属于 Model 部分的业务逻辑，因此完全不应该与i18n有关。异常也不必为此担心，因为绝对不应将异常按原样打印到UI（提供调试信息（不需要/不应本地化）除外）。

您的函数应仅返回true或false，并且一个完全独立的UI部分应将其转换为用户面对的内容，从而可能在过程中对其进行本地化。除了例外，它应该被装入适当本地化的UI的东西捕获，向用户解释问题。

何时（或缺乏）本地化是一件坏事？

4 个答案: