我正在使用Django在基于网络的应用程序上做一些i18n,它使用gettext作为其i18n基础。翻译应该存储在数据库中似乎是一个明显的想法,并不难做到,但文件系统上的po文件仍然被使用。这是为什么?
我目前的怀疑是,gettext作为一个完善的软件包的可靠性/熟悉程度简直超过了开发数据库的优势所带来的好处。还有其他重要原因继续将翻译存储在文件系统中吗?
答案 0 :(得分:8)
效果是主要原因。 Gettext没有使用数据库,因为数据库总是比文件慢得多。字典的加载时间非常重要,因此几乎每个人都在使用文件。
此外,已编译的gettext文件(.mo
)已针对在内存中加载进行了优化,因此它们比纯文本文件(如未编译的.po
文件)更合适。
您可以随时使用翻译平台(可能使用数据库后端)进行进行翻译并将结果导出到文本文件。示例:Pootle,Narro,Launchpad Rosetta,Transifex (hosted only)。
请勿将您的应用程序语言文件与本地化数据库混淆。您的应用程序应使用快速加载的基于文件的词典,您的本地化系统可能必须使用数据库,并且逻辑上能够将数据导出到文件。
顺便说一句,使用gettext
可能是您在本地化方面可能做出的最佳技术决策。我从未见过任何商业解决方案或内部开发能够在功能,工具甚至支持方面与之竞争。
答案 1 :(得分:3)
这是一种非常常见的翻译方式,这种翻译已经存在很长时间,可以解决多年来遇到的任何问题。我想像写一些像gettext一样,很容易对语言如何工作做出错误的概括。 Django开发团队为什么要花时间研究它并在已经经过试验和测试的系统中进行开发呢?此外,专业翻译人员可能知道如何处理PO文件,因为家庭酿造翻译数据库可能会阻止他们以他们习惯的方式工作。
为什么您更喜欢数据库中的翻译?我想你可能更喜欢它,因为你可以为数据库建立一个翻译界面。如果是这种情况,请查看Pootle它是一个功能强大的基于Web的翻译界面,可以直接使用PO文件,甚至可以与常见的版本控制系统集成。添加一些post-commit钩子,你可以拥有这样一个系统,只需很少的工作,而且没有翻译数据库的开销。
希望有所帮助。
答案 2 :(得分:2)
这似乎是一个明显的想法对你来说,我不认为每个人都会同意。 AFAIK django使用.po文件有以下原因:
顺便说一下,如果您需要为字段添加不同的翻译,那么问题就有点不同了,您应该检查http://www.muhuk.com/2010/01/dynamic-translation-apps-for-django/并选择最适合您需求的应用。