you topics tools sure newer multiidioma multi msguniq makemessages make language installed idioma i18n have example docs djangoproject commanderror django translation

tools - https docs djangoproject com en 2.0 topics i18n



¿Cuándo debería usar ugettext_lazy? (3)

Tengo una pregunta sobre el uso de ugettext y ugettext_lazy para las traducciones. Aprendí que en los modelos debería usar ugettext_lazy, mientras estoy en ugettext. ¿Pero hay otros lugares donde debería usar ugettext_lazy también? ¿Qué hay de las definiciones de formulario? ¿Hay diferencias de rendimiento entre ellos?

Editar: Y una cosa más. A veces, en lugar de ugettext_lazy , se usa ugettext_noop . Como dice la documentación, ugettext_noop cadenas ugettext_noop solo se marcan para la traducción y se traducen en el último momment posible antes de mostrarlas al usuario, pero estoy un poco confundido aquí, ¿no es similar a lo que hace ugettext_lazy ? Todavía es difícil para mí decidir, que debería usar en mis modelos y formularios.


ugettext() vs. ugettext_lazy()

En definiciones como formularios o modelos, debe usar ugettext_lazy porque el código de estas definiciones solo se ejecuta una vez (principalmente en el inicio de django); ugettext_lazy traduce las cadenas de una manera perezosa, lo que significa, por ejemplo. cada vez que accede al nombre de un atributo en un modelo, la cadena se traducirá por última vez, lo que tiene mucho sentido porque podría estar mirando este modelo en diferentes idiomas desde que se inició django.

En vistas y llamadas a funciones similares, puede usar ugettext sin problemas, ya que cada vez que se llame a la vista ugettext se ejecutará nuevamente, por lo que siempre obtendrá la traducción correcta que se ajuste a la solicitud.

En cuanto a ugettext_noop()

Como señaló Bryce en su respuesta, esta función marca una cadena como extraíble para la traducción pero devuelve la cadena sin traducir. Esto es útil para usar la cadena en dos lugares: traducido y sin traducir. Vea el siguiente ejemplo:

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


La versión diferida devuelve un objeto proxy en lugar de una cadena y, en alguna situación, no funcionaría como se esperaba. Por ejemplo:

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

fallaría porque la última línea intentaría serializar el objeto lst en JSON y en lugar de una cadena para "cliente" tendría un objeto proxy. El objeto proxy no se puede serializar en json.