Строки Grub в файлы .po, которые были переданы в ugettext как переменные

Я использую Django==1.8.4.

В приложении django я использую ugettext, чтобы получить переведенное сообщение следующим образом:

id = 1
message = "Some message %(id)s" % {'id':id}
return JsonResponse({'message': ugettext(message)})

В официальной документации django есть примечание относительно перевода переменных с помощью ugettext.

(Предостережение при использовании переменных или вычисленных значений, как в предыдущих двух примерах, заключается в том, что утилита Django для определения строки перевода, django-admin makemessages, не сможет найти эти строки. Подробнее о makemessages позже.

Источник: страница документации Django

Есть ли другой способ автоматически отправлять сообщения grub в файлы .po без рефакторинга всех вызовов ugettext (передавать прямую строку в ugettext вместо переменной)?


person Andriy Ivaneyko    schedule 29.04.2016    source источник


Ответы (1)


Вызовите ugettext для строкового литерала перед заменой переменных.

message = ugettext("Some message %(id)s") % {'id':id}
person Alvra    schedule 29.04.2016
comment
Спасибо, я знаю, что это возможно. Вопрос в том, как избежать такого рефакторинга. - person Andriy Ivaneyko; 29.04.2016
comment
Я так не думаю. Переменная message каждый раз будет разной, поэтому для каждой версии в файле .po потребуется генерировать сообщения. Как вы хотите, чтобы сообщения из вашего файла .po выглядели? Кстати, вы забыли {} вокруг словаря в аргументе JsonResponse; JsonResponse({'message': ugettext(message)}). - person Alvra; 29.04.2016
comment
канонический способ - аннотировать все переведенные исходные строки в исходном коде, то есть message = _("Some message %(id)s") % {'id':id}, чтобы сторонние инструменты могли найти все эти строки, то есть для статического анализа. (Obv, from xx import ugettext as _) Обратите внимание, что этот рефакторинг состоит всего из 3 символов для каждой строки, обращенной к пользователю, _(). Альтернативой является создание собственной цепочки инструментов ... А затем просто попробуйте объяснить это какому-нибудь другому разработчику, которому позже придется поддерживать ваш код. - person Dima Tisnek; 21.02.2017