5

我在我参与过的许多项目中都成功地使用了 GNU Gettext，但在我最近的工作中，我突然发现自己被迫使用一个非常尴尬的本地化系统。

当前系统将翻译存储在数据库中，添加新翻译的过程如下：

  • 将带有翻译键的函数调用添加到源代码，例如print translate('foo');
  • translations.sql向文件中添加一些 SQL INSERT 语句。
  • 用名字创建文件(current revision nr + 1).sql
  • 在数据库中执行 .sql 文件。
  • 提交您的更改（在其他人设法提交和更改当前修订号之前）。

所有这些过程都是完全手动的，即使您需要修复一个小错字，您也必须重复几乎所有的过程。不支持复数形式。整个翻译数据库非常混乱，因为翻译几乎从未被删除 - 只是添加和更新。

我尝试了几种论点来说服其他开发人员（尤其是一个特定的开发人员）：

  • 我已经谈到 Gettext 正在成为标准，并且有许多工具可用于处理 PO 文件。
  • 我试图解释在数据库中存储翻译与将它们存储到文本文件相比没有任何好处——我们只是通过密钥从数据库中检索翻译，仅此而已。
  • 另一位开发人员正在开发我们应用程序的 PHP 部分，PHP 内置了 Gettext。我在 JavaScript 方面工作，它不支持 Gettext，但我过去已经为它构建了自己的工具。
  • 我们的应用程序不是很大，即使手动完成从旧系统转换到 Gettext 也需要很长时间，我很确定它可以很容易地自动化。
  • 我什至成功地将 Gettext 用于我们公司的一个较小的应用程序。

但人们仍然不相信。我可能做错了什么？

编辑：

在发布这个问题几个月后，我们现在终于过渡到 Gettext。当我们需要支持两种以上的语言时，我们当前系统的缺点对那些迄今为止抵制它的人来说更加明显。

4

3 回答 3

6

你做错了什么是告诉他们如何解决他们认为不存在的问题。

你需要让他们看到这实际上是一个需要解决的问题。

编辑：
很高兴看到你最终到达那里，第二语言似乎让他们认出了房间里的大象！

于 2009-04-29T13:46:56.710 回答
2

我可以为您看到几个选项：

  • 您可以尝试使用您的方法估算节省的时间（金钱）。
  • 你可以展示（演示？）它是多么容易维护（减少头痛）。
  • 您可以继续使用已经存在的系统。
于 2009-04-29T13:45:35.853 回答
2

几个问题可能是：

缺乏对 Gettext 的认识。如果开发人员不了解该库，他们将不会使用它。

与 GPL 不兼容的许可证。不能使用它可能有法律原因。

看到不需要重写。如果开发人员对当前系统足够满意，那么他们可能会认为迁移到 Gettext 没有任何优势。

于 2009-04-29T13:54:17.847 回答