Quando dovrei usare ugettext_lazy?


141

Ho una domanda sull'uso di ugettext e ugettext_lazyper le traduzioni. Ho imparato che nei modelli dovrei usare ugettext_lazy, mentre nelle viste ugettext. Ma ci sono altri posti dove dovrei usare ugettext_lazyanche io ? Che dire delle definizioni dei moduli? Ci sono differenze di prestazioni tra loro?

Modifica: e un'altra cosa. A volte, invece di ugettext_lazy, ugettext_noopviene utilizzato. Come dice la documentazione, le ugettext_noopstringhe sono contrassegnate solo per la traduzione e tradotte all'ultimo momento possibile prima di mostrarle all'utente, ma sono un po 'confuso qui, non è simile a cosa ugettext_lazyfare? È ancora difficile per me decidere, che dovrei usare nei miei modelli e forme.

Risposte:


197

ugettext() vs. ugettext_lazy()

In definizioni come moduli o modelli dovresti usare ugettext_lazyperché il codice di queste definizioni viene eseguito una sola volta (principalmente all'avvio di django);ugettext_lazytraduce le corde in modo pigro, il che significa, ad esempio. ogni volta che accedi al nome di un attributo su un modello, la stringa verrà nuovamente tradotta, il che ha perfettamente senso perché potresti guardare questo modello in diverse lingue da quando è stato avviato django!

Nelle viste e chiamate di funzioni simili è possibile utilizzare ugettextsenza problemi, perché ogni volta che viene chiamata la vistaugettext verrà eseguita di nuovo, in modo da ottenere sempre la traduzione corretta adatta alla richiesta!

per quanto riguarda ugettext_noop()

Come ha sottolineato Bryce nella sua risposta, questa funzione contrassegna una stringa come estraibile per la traduzione, ma restituisce la stringa non tradotta. Questo è utile per usare la stringa in due punti: tradotto e non tradotto. Vedi il seguente esempio:

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

16
Secondo me è più comprensibile della spiegazione contenuta nella documentazione di Django. Grazie @ Bernardo.
Utku,

14
Grazie! Sarebbe anche utile spiegare quando non usare ugettext_lazy, come quando lo si passa a cose che si aspettano una stringa come "" .replace, concatenazione di stringhe e altre; un oggetto proxy pigro non funzionerà in questi casi. Altrimenti questa risposta implica che sei al sicuro usando sempre ugettext_lazy.
mrooney,

4
@mrooney quei casi contano meno perché ti daranno un errore se li fai, invece di restituire silenziosamente la traduzione della lingua sbagliata. Inoltre, puoi usare "" .replace con ugettext_lazy, devi solo chiamare str () sul risultato, ad es. Lazytext = ugettext_lazy ('ciao') e successivamente usare str (lazytext) .replace.
fabspro

1
che dire di msg = "An error has occurred"; logging.error(msg);return HttpResponse(_(msg))? why need _noop ?se senza _noop, django non ha trovato la stringa da tradurre?
WeizhongTu

1
La traduzione funziona su variabili. Ancora una volta, ecco un identico esempio di documenti , quindi perché _noop?
WeizhongTu


5

La versione pigra restituisce un oggetto proxy anziché una stringa e in alcune situazioni non funzionerebbe come previsto. Per esempio:

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

fallirebbe perché l'ultima riga proverebbe a serializzare il primo oggetto in JSON e invece di una stringa per "client" avrebbe un oggetto proxy. L'oggetto proxy non è serializzabile in json.


2
In questi casi dovresti usare ugettext.
sudip,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.