我什么时候应该使用ugettext_lazy?

问题:我什么时候应该使用ugettext_lazy?

我有一个关于使用ugettext和ugettext_lazy进行翻译的问题。我了解到,在模型ugettext_lazyugettext中,我应该在中使用。但是还有其他地方我也应该使用ugettext_lazy吗?表单定义呢?它们之间是否存在性能差异?

编辑: 还有一件事。有时候,代替ugettext_lazyugettext_noop被使用。正如文档所述,ugettext_noop仅在将字符串显示给用户之前,才将字符串标记为要翻译,并在可能的最新情况下进行翻译,但是我在这里有点困惑,这与功能相似ugettext_lazy吗?我仍然很难决定在模型和表格中应该使用哪个。

I have a question about using ugettext and ugettext_lazy for translations. I learned that in models I should use ugettext_lazy, while in views ugettext. But are there any other places, where I should use ugettext_lazy too? What about form definitions? Are there any performance diffrences between them?

Edit: And one more thing. Sometimes, instead of ugettext_lazy, ugettext_noop is used. As documentation says, ugettext_noop strings are only marked for translation and translated at the latest possible momment before displaying them to the user, but I’m little confused here, isn’t that similar to what ugettext_lazy do? It’s still hard for me to decide, which should I use in my models and forms.


回答 0

ugettext()ugettext_lazy()

在诸如表单或模型之类的定义中,您应该使用ugettext_lazy此定义,因为此定义的代码仅执行一次(通常在django启动时);ugettext_lazy以懒惰的方式翻译字符串,例如 每次访问模型上的属性名称时,字符串都会被重新翻译-这完全有意义,因为自django启动以来,您可能正在使用不同的语言查看该模型!

在视图和类似的函数调用中,您可以ugettext毫无问题地使用它,因为每次调用该视图时ugettext都会重新执行该视图,因此您将始终获得适合请求的正确翻译!

关于 ugettext_noop()

正如布莱斯在他的答案中指出的那样,此函数将字符串标记为可提取以进行翻译,但会返回未翻译的字符串。这对于在两个地方使用该字符串很有用-已翻译和未翻译。请参见以下示例:

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))

ugettext() vs. ugettext_lazy()

In definitions like forms or models you should use ugettext_lazy because the code of this definitions is only executed once (mostly on django’s startup); ugettext_lazy translates the strings in a lazy fashion, which means, eg. every time you access the name of an attribute on a model the string will be newly translated-which totally makes sense because you might be looking at this model in different languages since django was started!

In views and similar function calls you can use ugettext without problems, because everytime the view is called ugettext will be newly executed, so you will always get the right translation fitting the request!

Regarding ugettext_noop()

As Bryce pointed out in his answer, this function marks a string as extractable for translation but does return the untranslated string. This is useful for using the string in two places – translated and untranslated. See the following example:

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))

回答 1

_noop的一个很好的用法是,当您想以英语记录开发人员的消息,但将翻译后的字符串显示给查看者时。例如:http://blog.bessas.me/posts/using-gettext-in-django/

An excellent use of _noop, is when you want to log a message in English for the developers, but present the translated string to a viewer. An example of this is at http://blog.bessas.me/posts/using-gettext-in-django/


回答 2

惰性版本返回代理对象而不是字符串,并且在某些情况下无法正常工作。例如:

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,而不是“ client”的字符串,它将具有一个代理对象。代理对象无法序列化为json。

The lazy version returns a proxy object instead of a string and in some situation it would not work as expected. For example:

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')

would fail because very last line would try serialize lst object into JSON and instead of a string for “client” it would have a proxy object. The proxy object is not serializeable into json.