Just to add that if you do use django.utils.translation.get_language() then you should bear in mind that if that section of code will be called asynchronously (e.g. as a celery task) then this approach won't work due to it running in a different thread.
Be careful of the method you use to get the language. Depending on which method, Django will use different ways and informations to determine the right language to use.
When using the django.utils.translation.get_language() function, it's linked to the thread language. Before Django 1.8, it always returned settings.LANGUAGE_CODE when translations were disabled. If you want to manually override the thread language, you can use the override() or activate() functions, which is not very explicitly named, but well, still useful:
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
If you want django to check the path and/or request (language cookie, ...), which is a lot more common e.g. www.example.com/en/<somepath> vs www.example.com/fr/<somepath>, use django.utils.translation.get_language_from_request(request, check_path=False). Also, it will always return a valid language set in settings.LANGUAGES
I found it not very easy to find these differences through Google about this subject so here it is for further reference.
{% load i18n %}
{% get_current_language as LANGUAGE_CODE %}
Current language code: \{\{ LANGUAGE_CODE }}<br>
{% get_current_language_bidi as LANGUAGE_BIDI %}
{% if LANGUAGE_BIDI %}RTL <br>{% endif %}
{% get_language_info for LANGUAGE_CODE as lang %}
Language code: \{\{ lang.code }}<br>
Name of language: \{\{ lang.name_local }}<br>
Name in English: \{\{ lang.name }}<br>
Bi-directional: \{\{ lang.bidi }}
Name in the active language: \{\{ lang.name_translated }}