Comments 8
Почему-то думал что этого достаточно, без велосипедов…
Поскольку у вас уже есть Jinja2 в зависимостях, то можно воспользоваться его расширением gettext.
Тут можно посмотреть на него.
Я его и с Django пользую так:
Тут можно посмотреть на него.
Я его и с Django пользую так:
...
JINJA_CONFIG = {
'extensions': [
'jinja2.ext.i18n',
....
],
}
...
jinja2 все равно не может знать о местонахождении locale, поэтому ей нужно указывать откуда брать переводы.
А строчки:
и
Выполняют примерно одинаковую задачу. Но с небольшой разницей, get_trans() «знает» что такое модули, и каждому модулю предоставляет именно его файл переводов, исключая конфликты и пр.
А строчки:
jinja = Environment( extensions=['jinja2.ext.i18n'])
jinja.install_gettext_translations(translations)
и
kwarg['_'] = get_trans(module)
Выполняют примерно одинаковую задачу. Но с небольшой разницей, get_trans() «знает» что такое модули, и каждому модулю предоставляет именно его файл переводов, исключая конфликты и пр.
Инициализация ненужных переменных, названия переменных в стиле n, r, l, s, вложенные на 5 уровней циклы. Зачем вы делаете это с питоном?
почему не babel?
Если честно то я мало иследовал плюсы babel относительно gettext, при том что gettext более распространен. Насколько я понимаю фрагмент:
Для babel примерный аналог:
Разница не очень большая.
import gettext;
gettext.translation(domain, path, ['ru'], codeset='UTF-8')
Для babel примерный аналог:
from babel.support import Translations
Translations.load(dirname=resource_filename(__name__, 'locale'), locales=['ru'], domain='messages')
Разница не очень большая.
Sign up to leave a comment.
Django своими руками часть 2: Интернационализация