Хороший способ обеспечить поддержку Rails-way i18n в Django

Question

В Rails есть одна вещь, которой я завидую: поддержка интернационализации (есть и у Django, но я предпочитаю вкус Rails).

Ключевое различие между подходами Rails и Django заключается в том, какая строка ведет себя как ключи в отображении преобразования значения ключа, т.е.

Версия Django (ключи - строки на "основном" языке, например английском):

msgid "Save and quit"
msgstr "Zapisz i wyjdź"

Эквивалент версии Rails (ключи - абстрактные строки; автономное использование невозможно - необходимо предоставить хотя бы 1 «перевод») - фактически, Rails использует формат YAML, но следующий пример представляет идею:

// english translation file

msgid "SAVE_QUIT_MESSAGE"
msgstr "Save and quit"

и

// polish translation file

msgid "SAVE_QUIT_MESSAGE"
msgstr "Zapisz i wyjdź"

Способ поддержки i18n в Rails ИМХО намного лучше (подумайте о неизменности ключа - устойчив к грамматическим / орфографическим исправлениям; языковой агностицизм и т.д.).

Одним из способов использования этой схемы в Django было бы использование некоторого абстрактного языка с единственной целью перевода (строки на этом языке создавали бы неизменные ключи), но Django поддерживает только фиксированный набор языков. Другое решение - пожертвовать одним из поддерживаемых (неиспользуемых) языков, чтобы сыграть эту роль - но это просто плохо: P

Какие-либо идеи / сторонние приложения / методы для решения этой проблемы?

---

Sidenote: расширение поддержки i18n для языковых языков даст забавные возможности:

// slang translation file

msgid "SAVE_QUIT_MESSAGE"
msgstr "Save shit 'n' quit, bro"

Answer 1

Отойдите на минуту или две.Вы делаете тройную работу здесь.Сначала вы должны придумать UNIQUE_ID, а затем вынуждаете людей искать либо контекст из кода, либо из другого языкового файла, чтобы выяснить, каким будет правильное сообщение для AMBIGUOUS_ARGUMENT_PROVIDED, пока вы не приступите к предоставлениюактуальный перевод.И кто когда-либо говорил, что создание идентификаторов, которые могут значимо передать контекст и обеспечить хорошие подсказки для сообщений, было когда-либо легко?

Что вы пытаетесь сделать, это какой-то нелепый дерьмо, братан!Помимо шуток, причина, по которой gettext является наиболее распространенным и широко используемым API i18n и l10n, заключается в том, что каждому сообщению присваивается уникальный идентификатор каталога сообщений, назначенный из его содержимого, а также потому, что доказано, что у вас будет намного лучше переводить времясообщения, чем переводы идентификаторов, напоминают о том, что каждый пытался создать свой собственный каркас key-> value i18n, потому что он был наиболее простым для разработки.

В конечном итоге вы придете к выводу, что использовать gettext было плохой идеей.так, как это не было задумано, и вы можете спасти себя прямо сейчас, забыв обо всей идее.

Answer 2

Если вы настаиваете на том, чтобы делать это таким образом, то это можно сделать, сгенерировав файл .po, который будет содержать перевод на английский язык исходных строк.