什么时候应该使用ugettext_lazy？
我有一个关于使用ugettext和ugettext_lazy翻译的问题。 我了解到，在模型中，我应该使用ugettext_lazy，而在视图ugettext。 但是有没有其他的地方，我也应该使用ugettext_lazy？ 那么表单定义呢？ 他们之间有什么performance差异吗？
编辑：还有一件事。 有时，使用ugettext_noop而不是ugettext_lazy 。 正如文档所述， ugettext_noopstring只是标记为翻译和翻译之前，最新的可能momment才显示给用户，但我有点困惑在这里，是不是类似ugettext_lazy做什么？ 我仍然很难决定，我应该在我的模型和forms中使用哪一个。
ugettext()与ugettext_lazy()
在像表单或模型这样的定义中，应该使用ugettext_lazy因为这个定义的代码只执行一次（大部分是在django的启动时）。 ugettext_lazy以懒惰的方式翻译string，这意味着，例如。 每次你访问一个模型的属性的名字，string将会被新的翻译 – 这是完全有道理的，因为你可能正在从不同的语言看这个模型，因为django开始了！
在视图和类似的函数调用中，您可以使用ugettext而不会出现任何问题，因为每次调用ugettext都会重新执行ugettext ，所以您将始终获得适合请求的正确的转换。
关于ugettext_noop()
正如Bryce在他的回答中所指出的那样，这个函数将一个string标记为可翻译的string，但是会返回未翻译的string。 这对于在两个地方使用string非常有用 – 翻译和未翻译。 看下面的例子：
import logging from django.http import HttpResponse from django.utils.translation import ugettext as _, ugettext_noop as _noop def view(request): msg = _noop("An error has occurred") logging.error(msg) return HttpResponse(_(msg))
_noop的一个很好的用法是当你想用开发者的英文logging信息时，把翻译后的string呈现给查看者。 这方面的一个例子是http://blog.bessas.me/post/65775299341/using-gettext-in-django
懒惰版本返回一个代理对象，而不是一个string，在某些情况下，它不会像预期的那样工作。 例如：
def get(self, request, format=None): search_str = request.GET.get('search', '') data = self.search(search_str) lst = [] lst.append({'name': ugettext_lazy('Client'), 'result': data}) return HttpResponse(json.dumps(lst), content_type='application/json')
会失败，因为最后一行会尝试将lst对象序列化为JSON，而不是“客户端”的string，它将有一个代理对象。 代理对象不能序列化成json。
