I18n does not seem to work while modeltranslation does (a bit)

Question 1

I came across this post: Django internationalization language codes. Apparently, django only supports iso 639-1 language codes, which is not to be found in the documentation, even worse, it says you have to use codes like en-us. As soon as i changed the languages to en-us > en, nl-nl > nl etc. it worked immediately.

Anyway, thanks for the attention.

Question 2

I've found different platforms allow/prefer different language folder names. I was pulling my hair out on my development system (Mac OS X) because '/pt-br/LC_MESSAGES/' wouldn't work, even though makemessages created the folders that way and compile messages worked fine too. It finally sprang to life once I renamed the languages as '/pt_br/LC_MESSAGES/' (notice the underscore). Note my LANGUAGES tuple in settings uses the aa-bb form, just as you're using here.

Migrating the same project to production (Ubuntu), it stopped working again, I tried everything under the Sun thinking the folder names must already be correct since they work on my dev. machine. I finally, out of desperation tried uppercasing the country component like '/pt_BR/LC_MESSAGES/', and, boom, it started working again. I find that using the aa_BB form works universally.

So, the solution I think you're looking for is to change the names of the locale directories inside your locale folder. You should have:

[project]
    locale
        de_DE
        en_US
        es_ES
        fr_FR
        nl_NL
    ...
    settings.py

Inside each you'll have the LC_MESSAGES, etc. as normal of course. Your Django configuration shouldn't change, this is just what gettext accepts on your platform. Again, I think if you use the aa_BB form, you'll be fine on most systems.

If you need your locale folder in some other location for some reason, just make sure that you set the property settings.LOCALE_PATHS accordingly. Also, the Django documentation makes it clear how it finds this folder: https://docs.djangoproject.com/en/dev/topics/i18n/translation/#how-django-discovers-translations.

Question 3

I know it's been more than a year since this question has been answered, but i've ran into a similar problem and after many hours trying to figure out, i've finally come to a deterministic anwser.

Disclaimer: i'm using pt-br because is my mother language, but you can derive this to any language you want

First, what did i do on my django application (assuming you already have created project and app[s] and the current directory is the project dir):

created locale dir: mkdir locale
created a pt_BR locale: django-admin.py makemessages -l pt_BR
changed the text inside the created file
compiled all messages: django-admin.py compilemessages
added LOCALE_PATHS variable to django settings: LOCALE_PATHS =('/path/to/locale_foder',)

After this, my Django app was never being translated. No matter what i did...

According to django documentation (https://docs.djangoproject.com/en/dev/topics/i18n/translation/#how-django-discovers-language-preference) django has a predefined way to find language preferences, and this is how it works:

django search for the language prefix in the url, for this to work you must be using i18n_patterns in django url.
if the above fails, search for a variable in user session
if the above fails, search for a cookie
if the above fails, use the Accept-Language HTTP header
if the above fails, use the language specified in homonymous variable in django settings.

I've highlighted number 4 because, in my case, that's the one i'm using. This means my application is dependent on HTTP browser data.

Now, since we are dependent on HTTP data, let's check how the browser behaves. I mainly use chrome and firefox. My chrome has the following language settings on my notebook:

pt
en-us
en

And that is the problem, my Accept-Language HTTP header is sending pt, but i do not have pt locale, i only have a pt-br locale. If it was the other way around, this would work. My conclusion is that one should always have the iso 639-1 codes, and from there use specialisation. For example: i'm now using pt as default for pt-br, and pt-pt for Portugal specific translations.