更具描述性的语言字符串占位符？答案

【问题标题】：More descriptive Language String placeholder?更具描述性的语言字符串占位符？
【发布时间】：2009-12-18 15:44:48
【问题描述】：

<?LANG(no_download, 'you are not allowed to download')

而不是

$lang[no_download]

我认为在模板中嵌入语言字符串的更好方法。

在几乎所有 PHP 应用程序中，主要的语言占位符格式如 <?=$lang['no_download']?> 或 {{no_download}}。其他设计人员/开发人员/翻译人员将很难在不参考语言文件的情况下破译占位符所代表的内容。

为了使语言占位符更具描述性，我们为什么不将原始字符串与占位符一起包含在内？例如

<?=lang( 'no_download' , 'You are not allowed to download this file because you have exceeded your quota' )?>

第二个参数是一个虚拟参数，因此 lang() 函数没有对其进行任何操作。

乍一看，可能会认为它过于冗长，给模板标记添加了混乱。但在我看来，这不是一个有效的论点，因为如果语言字符串不支持语言，它会占用与占位符一样多的空间。

我想听听您对此的看法。

【问题讨论】：

【解决方案1】：

编辑 没有看到这被标记为 Smarty。如果您想要 Smarty 特定的答案，请忽略我的答案。

我不同意存在主要占位符格式。一般来说，格式取决于您处理翻译的方式，并且可能会有所不同。

除此之外，提供默认语言字符串作为翻译标签的情况并不少见。例如，在 Zend Framework 手册中，这是他们的usage example 的一部分。如果您的翻译适配器支持，那没有什么问题。如果它需要 ID，那么它不是一个选项。

就个人而言，我更喜欢 ID，并尝试根据它们在应用程序中的使用来命名它们，例如form.label.login.username 或 cart.checkout 或 flashmessage.notice。

使用 ID 还提供了另一层分离。鉴于发短信可能不属于开发人员或模板设计人员的职责，最好在模板中包含 ID。

【讨论】：

【解决方案2】：

在我看来，考虑为您的条目设置出色的描述性“键”更为明智...... 您的“no_download”键没有很好地描述消息，因为它缺少动词。

键，必须以良好的命名约定命名，以及变量和函数。

您的密钥应该是例如：

{{user_quota_exeeded}}

或

{{user_quota_exeeded_alert}}

从长远来看，如果你的“真实字符串”被改变而模板中的“虚拟参数”没有改变，它会欺骗你的一些同事/客户/...

此外，它会强制您输入两次消息。

wikipedia 上有关命名约定的更多信息。

【讨论】：

【解决方案3】：

Gettext 已经这样做了。它是这样的：

_('Gettext does this already. It goes something like this:');

【讨论】：

【解决方案4】：

这些都是很棒的答案，很棒的见解，伙计们。

Arno，我非常了解命名约定。我的示例语言键确实不是很恰当地命名，但它只是作为示例。在我的 Web 应用程序的整个翻译过程中，我遇到了难以用几个字符串概括/描述的字符串，因此想到了将默认语言字符串作为翻译标签。我敢肯定，如果您在翻译方面做了足够多的工作，您一定会遇到这种情况。

无论如何，看到 Zend 和 Gettext 已经采用了这种方法，这令人欣慰。

另一个突然出现在我脑海中的问题是性能损失。

会使用函数调用，例如LANG() ，比简单地打印出 $lang[] 数组占用更多的资源？

你怎么想的？

【讨论】：