使用或不使用 PHP 的本机 gettext 与自建的原因是什么？答案

【问题标题】：What are the reasons to use or to not use PHP's native gettext versus a self-build?使用或不使用 PHP 的本机 gettext 与自建的原因是什么？
【发布时间】：2011-03-25 15:42:36
【问题描述】：

为了让我的应用程序多语言化，我想知道 GNU 的 gettext 是否有很大的优势，或者构建自己的“库”是否有很大的劣势。

此外，如果更建议“构建自己的”，那么最佳做法是什么？显然它们必须存储在数据库中，我怀疑我想使用平面文件，所以在某些时候我最好缓存它们，我应该怎么做？

【问题讨论】：

你说缓存它们，在哪里.. 可能是平面文件。
哈哈，摸摸。但我的意思是把我的目录放在平面文件中。

标签： php localization multilingual gettext

【解决方案1】：

gettext 扩展有一些怪癖。

它将翻译字符串保存在内存中，因此在更新目录时可能需要重新启动（在 mod_php 运行时下）。
gettext API 并不是真正为 Web 应用程序设计的。（它会查找环境变量和系统设置。您必须用勺子喂食 Accept-Language 标头。）
很多人在设置时遇到问题。
另一方面，对 gettext 的工具支持更多。

手工制作的解决方案几乎总能减少您的麻烦。但话虽如此，gettext API 在简洁性方面是无与伦比的。 _("orig text") 或多或少是翻译文本的最佳界面。

如果您想自己编写代码，我建议您专注于此。

使用简单的函数名。一些 php 应用程序使用双下划线 __() 代替 _()。不要采用任何使实际使用翻译字符串变得麻烦的库。（例如，如果使用 Zend Framework，请始终编写包装函数。）
接受原始英文文本作为输入。避免助记翻译键（例如BTN_SUBMT）
在任何情况下都不要将数据库用于翻译目录。这些文本是运行时数据，而不是应用程序数据。（有关不好的示例，请参阅 osCommerce。）

您通常可以使用 PHP 数组脚本 lang/nl.php，其中只包含 $text["orig english"] = "dutch here";，这很容易通过您使用的任何访问方法来使用。

还要避免将所有内容都压入该系统。有时不可避免地会为较长的文本采用第二种机制。例如，我将 template/mail.EN.txt 用于更大的 blob。

【讨论】：

我同意。另一方面，gettext 几乎是受益于它的工具的“事实上的”标准：PO 编辑器、xgettext 和 msgmerge 是管理翻译时非常非常方便的工具。
感谢您详尽的回答，不过是一个问题。为什么像“BTN_SUBMIT”这样的索引是错误的？
@Gerben Jacobs：他们本身并没有错。但回想起来，我希望我能避免这个计划。这是define("TEXT_BTN_NAME", "Button Name") 的一种非常典型的PHP 方法。但这使得以后过渡到其他系统变得更加困难，最重要的是使源代码的可读性降低了一些。使用缩写通常是基于您希望始终更改文本内容的错误假设。在实践中并非如此。编写您的应用程序，并在最后进行翻译。一次完成而不是逐步完成会更简单。但除此之外，ABBRV 并没有真正的技术问题。
我更喜欢翻译键，因为当你想更改英文翻译时，你必须在很多地方替换它。此外，翻译键可以包含有关翻译字符串的目的/预期用途的元信息。

【解决方案2】：

Gettext 是not thread-safe。

在决定实施你自己的之前，我建议你看一下Zend_Translate。它原生支持 gettext 适配器，以及 TMX、CSV、INI、Array 和更多格式。如果不支持您的首选格式（例如数据库存储），编写您自己的适配器也应该很容易。

【讨论】：

仅供参考：setlocale 因此gettext 不是线程安全的，因为环境变量不是线程安全的。不过，添加新的代理环境 API 听起来是个好主意。
gettext 不是线程安全的，但在许多情况下并不重要：stackoverflow.com/questions/1646249/…。 Zend-translate 很不错，但比 PHP 的内置模块要胖而且肯定慢得多。