Почему gettext не имеет опция хранения базы данных?
Я работаю над i18n для веб-приложения с использованием Django, которое использует gettext в качестве основы i18n. Кажется очевидной идеей, что переводы должны храниться в базе данных, и это не сложно сделать, но po файлы в файловой системе все еще используются. Почему это так?
Мое нынешнее подозрение заключается в том, что преимущества разработки db backaged просто перевешиваются надежностью / знакомостью gettext как хорошо известного пакета. Существуют ли другие существенные причины для продолжения хранения переводов в файловой системе?
2 ответа
Это кажется очевидной идеей для вас , я не думаю, что все согласятся. AFAIK django использует файлы .po по следующим причинам:
- Контроль версий - вам придется создать дополнительные инструменты «.po в базу данных», потому что вам все равно нужно поддерживать разных людей, работающих над переводами, и вы не можете уйти от наличие файлов .po для этой цели
- gettext - это стандартный способ выполнения переводов в мире .nix, есть много инструментов для работы с ним, его просто редактировать, сравнивать и т. д.
- Нет необходимости обращаться к базе данных, если вам нужно что-нибудь перевести. Некоторые представления могут работать без каких-либо запросов к базе данных, поэтому нет необходимости привязывать их к базе данных только для того, чтобы получить перевод. (Возможно, я ошибаюсь, но в случае mod_wsgi - переводы будут загружаться один раз и сохраняться в памяти для каждого потока).
Кстати, если вам нужны разные переводы полей, это немного другой вопрос, и вам следует проверить http://www.muhuk.com/2010/01/dynamic-translation-apps-for-django / и выберите приложение, которое лучше всего соответствует вашим потребностям.
Это очень распространенный способ перевода, который существует уже давно, позволяющий решать любые проблемы на протяжении многих лет. Я полагаю, что, написав что-то вроде gettext, было бы слишком легко делать неправильные обобщения о том, как работают языки. Зачем команде разработчиков Django тратить время на изучение и разработку этого, если это уже сделано в испытанной и протестированной системе? Кроме того, профессиональные переводчики, вероятно, знают, что делать с PO-файлами, поскольку домашняя база данных переводов может помешать им работать так, как они привыкли.
Почему вы предпочитаете переводы в базе данных? Я думаю, вы могли бы предпочесть это, поскольку вы могли бы сделать интерфейс перевода для базы данных. Если это так, обратите внимание на Pootle , это мощный веб-интерфейс перевода, который работает напрямую с PO-файлами и может даже интегрироваться с общими системами контроля версий. Добавьте несколько ловушек после фиксации, и вы сможете получить такую систему с небольшим трудом и без накладных расходов на базу данных переводов.
Надеюсь, что это поможет.