2010-07-28 16 views

risposta

97

Le funzioni di particolare interesse sono django.utils.translation.get_language() che restituisce la lingua utilizzata nel thread corrente. Vedi documentation.

+0

Il link è ora rotto, dovrebbe essere [questo] (https://docs.djangoproject.com/es/1.9/ref/utils/#django.utils.translation.get_language). – LostMyGlasses

+1

Avvertenza: * Restituisce Nessuno se le traduzioni sono temporaneamente disattivate (da deactivate_all() o quando None viene passato a override()). Prima di Django 1.8, get_language() restituiva sempre LANGUAGE_CODE quando le traduzioni erano disattivate. * – Pieter

0

È possibile leggere il sistema locale per informazioni sulla lingua.

+5

Sei moderato a -3, ma penso che la domanda sia vaga - "la lingua corrente del mio web". Non è colpa tua per aver indovinato questo significa OS. – mikemaccana

68

Oppure si può anche ottenere questo nel vostro punto di vista

request.LANGUAGE_CODE
+5

Ho votato per questo (da -1 per qualche motivo). Si noti quanto segue (da http://docs.djangoproject.com/en/dev/topics/i18n/deployment/#how-django-discovers-language-preference "con la traduzione statica (senza il middleware), la lingua è nelle impostazioni .LANGUAGE_CODE, mentre con la traduzione dinamica (middleware), è in request.LANGUAGE_CODE. " –

+3

Questo link è morto e non vedo alcun motivo per non utilizzare la soluzione accettata documentata sopra:' django.utils.translation.get_language() ' – qris

+2

cercare di ottenere la lingua, ad esempio, i modelli non sarebbe possibile se non ci fosse ancora una richiesta. Penso che il '' 'django.utils.translation.get_language()' '' sia sempre una soluzione migliore. – Hussam

7

solo aggiungere che se si fa uso django.utils.translation.get_language() allora si dovrebbe tenere a mente che se quella sezione di codice sarà chiamato in modo asincrono (ad esempio, come un sedano compito) quindi questo approccio non funzionerà a causa di esso in esecuzione in un thread diverso.

+2

L'approccio ovvio qui sarebbe quello di passare la lingua come compito parametrico ter, quindi impostare la lingua con la traduzione.activate (lingua) – xyzman

21

Fare attenzione al metodo utilizzato per ottenere la lingua. A seconda del metodo, Django utilizzerà diversi modi e informazioni per determinando la lingua corretta da utilizzare.

Quando si utilizza la funzione django.utils.translation.get_language(), è collegata alla lingua thread. Prima di Django 1.8, restituiva sempre settings.LANGUAGE_CODE quando le traduzioni erano disabilitate. Se si desidera ignorare manualmente la lingua filo, è possibile utilizzare i override() o activate() funzioni, che non è molto esplicitamente nominato, ma bene, comunque utili:

from django.utils import translation 

with translation.override('fr'): 
    print(_("Hello")) # <= will be translated inside the with block 

translation.activate('fr') # <= will change the language for the whole thread. 
# You then have to manually "restore" the language with another activate() 
translation.activate('en') # <= change languages manually 

Se vuoi Django per controllare il percorso e/o richiesta (cookie della lingua, ...), che è molto più comune ad esempio www.example.com/en/<somepath> vs www.example.com/fr/<somepath>, utilizzare django.utils.translation.get_language_from_request(request, check_path=False). Inoltre, verrà sempre restituita una lingua valida impostata in settings.LANGUAGES

Non ho trovato molto semplice trovare queste differenze tramite Google su questo argomento, quindi è qui per ulteriori riferimenti.

+0

Si noti che è 'django.utils.translation', non traduzioni. C'è un errore di ortografia nel link fornito. Nello snippet è corretto. – J0ANMM

+0

@ J0ANMM: grazie, corretto;) – achedeuzot

+1

+1 per la differenza tra 'django.utils.translation.get_language()' e 'django.utils.translation.get_language_from_request (request, check_path)'. Se sei in vista, dovresti usare quest'ultimo con 'check_path = True' per ottenere la lingua in cui il tuo template verrà visualizzato. –

Problemi correlati