以下代码返回一条消息,指出输入值是否是回文:
(就本文而言,语法并不重要,或以任何特定语言编写)
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();
}
}
在此示例中,请注意,无法在异常中本地化消息。我知道在第一个示例中可以使用相同的原理轻松解决此问题,但它的目的是为了证明缺乏全球化。
因此,什么时候应该将全球化应用于代码,以便可以对它进行本地化?什么时候重要,什么时候不重要?
答案 0 :(得分:1)
我相信,没有理想的答案-一切都取决于您的体系结构和用例。
但是,我建议使用以下模式:
通常,以英语获取所有技术数据(日志,错误等)是一个好习惯。用户必须了解所有面向用户的数据。
答案 1 :(得分:0)
这在很大程度上取决于您的用例。我建议立即本地化显示在前端的消息。我的经验是,稍后进行此操作非常昂贵。对于调试或监视消息,我可能只会用英语完成,因为大多数开发人员都可以阅读英语消息。
答案 2 :(得分:0)
所有标签都需要翻译。
对于此定义,文本是最终用户读取的信息。在这种情况下,标签是一段文本,它同时不是用户输入或用户数据。
举个例子,在“另存为” 对话框中,文件名将是用户输入,即文件内容 用户数据和两个按钮上的保存和取消标签将是标签(因此需要翻译)。
鉴于此定义,规则如下:
只需翻译用户界面代码,它就会翻译所有标签。相反,不直接面对最终用户(例如库或后端服务)的业务逻辑代码根本不会翻译。此外,除了用户输入或用户数据之外,业务逻辑实现或业务逻辑 API 均不处理文本。
因此,该规则还暗示将业务逻辑代码与用户界面代码完全分开。进行测试非常方便。
以回文示例为例,该函数将为业务逻辑,并且不会返回文本,而是更合适的示例,例如布尔值或枚举。然后,用户界面代码将评估返回值并对其进行适当的翻译。例外情况也是如此。
答案 3 :(得分:0)
应该进行本地化的唯一位置是UI。如果您坚持MVC的separation of concerns原则(或类似MVP之类的东西),那么本地化将完全发生在 View 部分。您的isPalindrome
函数听起来更像属于 Model 部分的业务逻辑,因此完全不应该与i18n有关。异常也不必为此担心,因为绝对不应将异常按原样打印到UI(提供调试信息(不需要/不应本地化)除外)。
您的函数应仅返回true
或false
,并且一个完全独立的UI部分应将其转换为用户面对的内容,从而可能在过程中对其进行本地化。除了例外,它应该被装入适当本地化的UI的东西捕获,向用户解释问题。