web-dev-qa-db-ja.com

いつugettext_lazyを使用すべきですか？

翻訳にugettextとugettext_lazyを使用することについて質問があります。モデルではugettext_lazyを使用し、ビューではugettextを使用する必要があることを学びました。しかし、ugettext_lazyも使用すべき他の場所はありますか？フォーム定義はどうですか？それらの間にパフォーマンスの違いはありますか？

編集：そしてもう1つ。時には、ugettext_lazyの代わりにugettext_noopが使用されます。ドキュメントにあるように、ugettext_noop文字列は、ユーザーに表示する前に、翻訳のマークが付けられ、可能な限り最新の時点で翻訳されますが、ここでは少し混乱していますが、ugettext_lazy ？私がモデルやフォームで使用すべきものを決定するのはまだ難しいです。

pythondjangotranslation
125
Dzejkob

ugettext() vs. ugettext_lazy()

フォームやモデルなどの定義では、_ugettext_lazy_を使用する必要があります。この定義のコードは1回しか実行されないためです（主にDjangoの起動時に）。 _ugettext_lazy_は、文字列を遅延形式で変換します。モデルの属性の名前にアクセスするたびに、文字列が新しく翻訳されます。これはDjangoが開始されてからこのモデルを異なる言語で見ている可能性があるためです。

ビューおよび同様の関数呼び出しでは、ビューが呼び出されるたびにugettextが新しく実行されるため、問題なくugettextを使用できます。したがって、常に要求に合った適切な翻訳を取得できます。

ugettext_noop()について

Bryce の回答で指摘したように、この関数は文字列を翻訳用に抽出可能としてマークしますが、翻訳されていない文字列を返します。これは、翻訳済みと未翻訳の2つの場所で文字列を使用する場合に便利です。次の例を参照してください。

_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))
_
176
Bernhard Vallant

_noopの優れた使用法は、開発者向けに英語のメッセージを記録し、翻訳された文字列をビューアに提示する場合です。この例は http://blog.bessas.me/posts/using-gettext-in-Django/ にあります

16
Bryce

遅延バージョンは文字列の代わりにプロキシオブジェクトを返し、状況によっては期待どおりに動作しません。例えば：

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にシリアライズしようとし、「クライアント」の文字列の代わりにプロキシオブジェクトを持つため、失敗します。プロキシオブジェクトはjsonにシリアル化できません。

5
Alex Protyagov