5

哪个更好：

  1. 获取文本
  2. 自定义基于 MySQL+缓存的功能

Gettext 是一种内置功能，因此我认为它已针对性能进行了调整。使用 poedit 很痛苦，不可能向任何客户展示。

自定义功能允许简单的翻译界面。但可能对 php/db 的使用很重。

我想，你什么时候会用哪一个？

4

3 回答 3

17

本地化很困难。这真的很难。不仅仅是"pairs of words" => "Wortpaare"，它比这复杂得多。大多数人在看到 gettext 并感到“呃，丑陋”时忘记的是，本地化过程比实现的技术细节重要得多。那是因为实际的翻译人员通常不是程序员，甚至可能不是内部人员。这导致的头痛比你想象的要多得多。gettext 真的很老了，经过实战考验，背后有一个巨大的工具链，经过调整以支持这个过程。如果你想正确地做 i18n 和 l10n，你需要一个强大的系统。gettext 就是这样，并且得到了广泛工具的支持。您的 Homebrewed Translation System™ 不会。

首先，您需要一个强大的系统来提取可翻译的字符串。由于无法自动且可重复地从源代码中提取可翻译字符串，您需要为每个要翻译的新字符串做大量工作。在 gettext 中，xgettext这样做。

接下来，您需要一个工具来将提取的字符串与已经存在的翻译同步，这样就不会丢失任何翻译，并且如果可能的话，只保留稍微更改的翻译。在 gettext 中，msgmerge这样做。

接下来，您需要一种向字符串添加额外信息的方法。您希望能够按类别、“域”和上下文对它们进行分组，您可能希望为翻译者添加对源代码的注释，并且您可能希望翻译者能够向翻译添加注释。gettext 支持所有这些。

接下来，您需要一种能够从各种工具中获得良好支持的文件格式，因为您可能会将文件发送到中国以便在那里进行翻译。您可能将它们发送给外部翻译的原因也是您需要一个好的同步工具来合并更改的原因，因为这可能是一个非常异步的过程。PO 文件得到很好的支持，因为 gettext 太老了。根据您的具体需求，有许多开源和商业工具在多个层面支持本地化过程。

不要低估本地化的任务，选择一个非常适合该过程的工具并学习它。gettext 是一个很棒的工具，虽然它不是最适合初学者的。

值得一提的是，这是我的 Twig 的 gettext 扩展，它使 PHP 的 gettext 变得更好。

于 2013-03-11T16:00:32.023 回答
2

也许您应该研究一下可以与 MySQL 结合使用的Memcached 。它对于获取不经常更改的数据（例如翻译）非常有用。

于 2013-03-11T15:06:39.960 回答
0

Gettext 是一种非常古老的格式。它使用文件来存储翻译。它很笨拙，尤其是当您有成千上万的翻译时，可以说是 20,000。管理包含 20,000 个翻译字符串的 PO 文件是一场噩梦，跨 50 种语言是不可能的。然后你必须在 MO 文件中实际编译它。不，谢谢。这在 1990 年可能是有意义的，而不是现在。

相反，数据库功能强大。就像真的很强大。说出你需要的东西，你就能得到它。他们可以在一秒钟内准确地告诉你：

  • 哪个翻译字符串没有翻译成哪种语言
  • 翻译最初是何时创建的，由谁创建
  • 翻译最后一次更新是什么时候以及由谁更新
  • 每次翻译的完整历史记录与完成更改的人
  • 您可以在物化视图中预翻译所有文本，并通过一个 select 语句获取它们
  • 按字母顺序排列翻译字符串，逐页查看和编辑
  • 设置哪些用户可以准确更新哪些翻译
  • 使用一些简单的 HTML Web 表单，世界上任何地方的任何人都可以在几秒钟内实时翻译您的应用程序，并且具有完整的历史记录、评论每个翻译对、接收和阅读回复、标记待办事项的翻译等等等
  • 在几秒钟内分析谁在过去的一天、一周、一个月、一年中完成了多少翻译 - 这样您就可以给予奖励
  • 还需要 PO 文件吗？您可以按照您需要的时间表让您的数据库创建这些
  • 缺少翻译？您的数据库可以自动向负责该语言的翻译人员发送电子邮件、短信。
  • 翻译已被翻译更新？现在数据库可以向负责的审阅者发送电子邮件以进行审批
  • 需要快速翻译？您的数据库可以立即调用 API 进行翻译，然后发送电子邮件给负责人进行审核
于 2021-09-12T10:18:06.063 回答