Quand dois-je utiliser ugettext_lazy?

Question

J'ai une question sur l'utilisation de ugettext et ugettext_lazy pour les traductions. J'ai appris que dans les modèles que je devrais utiliser ugettext_lazy, tandis que dans les vues ugettext. Mais existe-il d'autres endroits, où je dois utiliser ugettext_lazy trop? Ce que sur la forme des définitions? Existe-il des performances de diffrences entre eux?

Edit: Et une chose de plus. Parfois, au lieu de ugettext_lazy, ugettext_noop est utilisé. La documentation dit, ugettext_noop chaînes ne sont marquées pour la traduction et traduit le plus tard possible momment avant de les afficher à l'utilisateur, mais je suis un peu confus, ici, n'est-ce pas similaire à ce que l' ugettext_lazy ? Il est toujours difficile pour moi d'en décider, lequel dois-je utiliser dans mon de modèles et de formes.

Answer 1

Dans les définitions comme des formes ou des modèles que vous devez utiliser ugettext_lazy parce que le code de cet définitions n'est exécuté qu'une seule fois (la plupart du temps sur django de démarrage); ugettext_lazy se traduit par les chaînes dans un paresseux de la mode, ce qui signifie, par exemple. chaque fois que vous accédez au nom d'un attribut sur un modèle de la chaîne de caractères sera nouvellement traduits, ce qui les rend totalement de sens parce que vous pourriez être à la recherche à ce modèle en plusieurs langues depuis django a été commencé!

Dans les vues similaires et des appels de fonction, vous pouvez utiliser ugettext sans problèmes, parce que chaque fois que la vue est appelée ugettext seront nouvellement exécuté, de sorte que vous aurez toujours le droit de traduction, adaptation de la demande!

Answer 2

Une excellente utilisation de _noop consiste à consigner un message en anglais pour les développeurs, mais à présenter la chaîne traduite à un visualiseur. Un exemple de ceci est à http://blog.bessas.me/post/65775299341/using-gettext-in-django

Answer 3

La version lazy renvoie un objet proxy au lieu d'une chaîne et, dans certains cas, cela ne fonctionnerait pas comme prévu. Par exemple:

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

échouerait parce que dernière ligne tenterait sérialisation objet LST en JSON et au lieu d'une chaîne pour « client » il aurait un objet proxy. L'objet proxy n'est pas sérialisable dans json.