Localization 什么时候本地化（或缺乏本地化）是一件坏事？

以下代码返回一条消息，说明输入值是否为回文：

（就这篇文章而言，语法并不重要，也不是用任何特定的语言写的）

注意，在上面的代码中，默认消息是用英语编写的，但是由于它们是作为参数提供的，所以这个方法很容易本地化，并且因为该方法具有消息的默认值，所以这并不强制开发人员提供它们；例如：

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

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

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

然而，我们可以证明本地化；例如，在西班牙语中：

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

这让我想到，什么时候应该在设计代码时考虑本地化

另一个例子是例外情况；例如：

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

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

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

请注意，在本例中，无法在异常中本地化消息。我知道，使用第一个例子中的相同原则可以很容易地解决这个问题，但它的目的是为了证明全球化的缺失

---

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

这在很大程度上取决于您的用例。我建议立即将显示在前端的消息本地化。我的经验是，以后做这件事要花很多钱。对于调试或监视消息，我可能只使用英语，因为大多数开发人员都能够阅读英语消息。

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

不过，我建议采取以下模式：

所有日志消息（服务器和客户端）都应使用英语

所有错误API响应应始终提供英文描述和唯一的错误代码，您可以在客户端将其翻译为友好消息

为了提供良好的用户体验，所有客户端消息都应该使用用户的语言

---

一般来说，最好将所有技术数据（日志、错误等）用英语书写。所有面向用户的数据必须是用户可以理解的。

所有标签都需要翻译

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

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

根据这一定义，规则如下：

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

因此，该规则还意味着将业务逻辑代码与用户界面代码完全分离。这对于测试来说非常方便

---

对于回文示例，函数将是业务逻辑，它不会返回文本，而是更合适的内容，例如布尔值或枚举。用户界面代码将对返回进行评估，并对其进行适当的翻译。这同样适用于例外情况。

唯一应该进行本地化的地方是在UI中。如果您坚持的原则是（或类似MVP之类的），那么本地化只在视图部分进行。您的

isAlindrome

函数听起来更像是属于模型部分的业务逻辑，因此根本不应该与i18n有关。异常也不应该担心，因为任何异常都不应该按原样打印到UI（除了提供调试信息，不需要/不应该本地化）

您的函数应该只返回

true

或

false

，一个完全独立的UI部分应该将其转换为面向用户的内容，并可能在过程中对其进行本地化。与异常情况相同，它应该被加载适当本地化的UI并向用户解释问题的东西捕获