何时(或缺乏)本地化是一件坏事?

时间:2018-12-17 21:38:42

标签: localization language-agnostic globalization

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

(就本文而言,语法并不重要,或以任何特定语言编写)

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();
    }
}

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

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

4 个答案:

答案 0 :(得分:1)

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

但是,我建议使用以下模式:

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

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

答案 1 :(得分:0)

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

答案 2 :(得分:0)

所有标签都需要翻译。

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

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

鉴于此定义,规则如下:

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

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

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

答案 3 :(得分:0)

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

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