【问题标题】:When is localization (or lack of) a bad thing?什么时候本地化(或缺乏)是一件坏事?
【发布时间】:2018-12-17 21:38:42
【问题描述】:

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

(为了这篇文章,语法并不重要,或者用任何特定的语言编写)

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

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

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

【问题讨论】:

    标签: localization language-agnostic globalization


    【解决方案1】:

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

    但是,我建议以下模式:

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

    一般来说,所有技术数据(日志、错误等)都以英文提供是一种很好的做法。所有面向用户的数据都必须便于用户理解。

    【讨论】:

      【解决方案2】:

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

      【讨论】:

        【解决方案3】:

        唯一应该进行本地化的地方是在 UI 中。如果您坚持 separation of concernsMVC 原则(或类似 MVP 等),那么本地化只发生在 View 部分。您的 isPalindrome 函数听起来更像是属于 Model 部分的业务逻辑,因此根本不应该关心 i18n。异常也不应该担心它,因为任何异常都不应该按原样打印到 UI(除了提供调试信息,它不需要/不应该被本地化)。

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

        【讨论】:

          【解决方案4】:

          所有标签都需要翻译。

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

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

          根据这个定义,规则如下:

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

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

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

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2014-07-22
            • 2011-04-27
            • 1970-01-01
            • 2011-06-03
            • 2019-09-27
            • 2010-09-06
            • 2010-10-26
            相关资源
            最近更新 更多