我正在使用 Django 在基于 Web 的应用程序上进行一些 i18n 操作，该应用程序使用 gettext 作为其 i18n 基础。翻译应该存储在数据库中似乎是一个显而易见的想法，而且并不难做到，但文件系统上的 po 文件仍在使用。这是为什么呢？
我目前的怀疑是，开发一个数据库备份的好处完全被 gettext 作为一个完善的软件包的可靠性/熟悉性所抵消。继续将翻译存储在文件系统上还有其他重要原因吗？
I'm doing some i18n on a web-based app using Django, which uses gettext as its i18n foundation. It seems like an obvious idea that translations should be stored in the database, and not difficult to do, but po files on the filesystem are still being used. Why is this?
My current suspicion is that the benefits of developing a db backaged are simply outweighed by the reliability/familiarity of gettext as a well-established package. Are there other significant reasons for continuing to store the translations on the filesystem?
发布评论
评论（3）
性能是主要原因。 Gettext 不使用数据库，因为数据库总是比文件慢得多。字典的加载时间非常重要，因此几乎每个人都使用文件来加载。
此外，已编译的 gettext 文件 (
.mo) 已针对加载到内存中进行了优化，因此它们比纯文本文件（如未编译的.po文件）更合适）。您始终可以使用翻译平台（可能使用数据库后端）来进行翻译并将结果导出到文本文件。示例：Pootle、Narro，Launchpad Rosetta，Transifex（仅托管）。
不要将应用程序语言文件与本地化数据库混淆。您的应用程序应该使用加载速度快的基于文件的字典，并且您的本地化系统可能必须使用数据库并在逻辑上能够将数据导出到文件。
顺便说一句，使用
gettext可能是您在本地化方面能够做出的最佳技术决策。我从未见过任何商业解决方案或内部开发的解决方案能够在功能、工具甚至支持方面与它竞争。Performance is the main reason. Gettext is not using a database because a database will always be considerably slower than a file. The load time of the dictionary is very important and for this reason almost everyone is using files for that.
Also, the compiled gettext files (
.mo) are optimized for loading in memory and for this reason they are more appropriate than plain text files (like not-compiled.pofiles).You can always use translation platform, probably that uses a database backend, for doing the translation and export the results to text files. Examples: Pootle, Narro, Launchpad Rosetta, Transifex (hosted only).
Do not confuse your application language files with the localization database. Your application should use file based dictionaries that are fast to load and your localization system probably will have to use a database and logically be able to export data to files.
By the way, using
gettextis probably the best technological decision you may be able to make regarding localization. I never seen any commercial solution or in-house developed to be able to compete with it on features, tools and even support.这是一种非常常见的翻译方式，已经存在很长时间了，多年来可以解决任何问题。我想象编写像 gettext 这样的东西很容易对语言的工作方式做出错误的概括。当 Django 开发团队已经在经过尝试和测试的系统中完成它时，为什么还要花时间研究和开发它呢？此外，专业翻译人员可能知道如何处理 PO 文件，因为自制翻译数据库可能会阻止他们以他们习惯的方式工作。
为什么您更喜欢数据库中的翻译？我想您可能更喜欢它，因为您可以为数据库创建翻译接口。如果是这种情况，请查看 Pootle，它是一个功能强大的基于网络的翻译界面，可以使用直接与 PO 文件集成，甚至可以与常见的版本控制系统集成。添加一些提交后挂钩，您只需很少的工作就可以拥有这样的系统，并且无需翻译数据库的开销。
希望有帮助。
It's a very common way to do translations that has been around for a long time allowing any issues to be ironed out over the years. I imagine writing something like gettext it would be all too easy to make incorrect generalisations about how languages work. Why should the Django development team spending time researching that and developing it when it's already been done in a tried and tested system? Furthermore professional translators probably know what to do with PO files where as a home-brew translation database may prevent them from working in ways they're used to.
Why would you prefer translations in a database? I guess you might prefer it as you could make a translation interface to the database. If that's the case have a look at Pootle it's a powerful web-based translation interface that works directly with PO files and can even integrate with common version control systems. Add some post-commit hooks and you can have such a system with little work and without the overhead of a translations database.
Hope that helps.
对你来说这似乎是一个显而易见的想法，但我不认为每个人都会同意。 AFAIK django 使用 .po 文件的原因如下：
顺便说一句，如果您需要对字段进行不同的翻译，这是一个有点不同的问题，您应该检查 http://www.muhuk.com/2010/01/dynamic-translation-apps-for-django/ 并选择最适合您需求的应用程序。
This seems like an obvious idea for you, I don't think everybody will agree. AFAIK django uses .po files for following reasons:
Btw, if you need to have different translations for fields, it's a bit different question and you should check http://www.muhuk.com/2010/01/dynamic-translation-apps-for-django/ and choose app that best fit your needs.