Python 我应该什么时候使用 ugettext_lazy？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4160770/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When should I use ugettext_lazy?
提问by Dzejkob
I have a question about using ugettext and ugettext_lazyfor 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_lazytoo? What about form definitions?
Are there any performance diffrences between them?
我有一个关于使用 ugettext 和ugettext_lazy翻译的问题。我了解到在模型中我应该使用ugettext_lazy，而在视图中使用 ugettext。但是还有其他地方我也应该使用ugettext_lazy吗？表单定义呢？它们之间有任何性能差异吗？
Edit:And one more thing. Sometimes, instead of ugettext_lazy, ugettext_noopis used. As documentation says, ugettext_noopstrings 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_lazydo? It's still hard for me to decide, which should I use in my models and forms.
编辑：还有一件事。有时候，代替ugettext_lazy，ugettext_noop被使用。正如文档所说，ugettext_noop字符串只被标记为翻译，并在向用户显示之前在最晚的时刻进行翻译，但我在这里有点困惑，这不是类似于做什么ugettext_lazy吗？我仍然很难决定，我应该在我的模型和表单中使用哪个。
采纳答案by Bernhard Vallant
ugettext()vs. ugettext_lazy()
ugettext()对比 ugettext_lazy()
In definitions like forms or models you should use ugettext_lazybecause the code of this definitions is only executed once (mostly on django's startup); ugettext_lazytranslates 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!
在像表单或模型ugettext_lazy这样的定义中你应该使用，因为这些定义的代码只执行一次（主要是在 django 启动时）；ugettext_lazy以懒惰的方式翻译字符串，这意味着，例如。每次您访问模型上的属性名称时，该字符串都将被新翻译 - 这完全有道理，因为自 django 启动以来，您可能正在以不同的语言查看此模型！
In views and similar function calls you can use ugettextwithout problems, because everytime the view is called ugettextwill be newly executed, so you will always get the right translation fitting the request!
在视图和类似的函数调用中，您可以ugettext毫无问题地使用，因为每次调用视图时ugettext都会重新执行，因此您将始终获得适合请求的正确翻译！
Regarding ugettext_noop()
关于 ugettext_noop()
As Brycepointed 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))
回答by Bryce
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/
_noop 的一个很好的用途是，当您想用英语为开发人员记录一条消息，但将翻译后的字符串呈现给查看器时。这方面的一个例子是http://blog.bessas.me/posts/using-gettext-in-django/
回答by Alex Protyagov
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 lstobject into JSON and instead of a string for "client" it would have a proxy object. The proxy object is not serializeable into json.
会失败，因为最后一行会尝试将lst对象序列化为 JSON，而不是“客户端”的字符串，它会有一个代理对象。代理对象不可序列化为 json。
