Question

I’ve setup translated urls for some languages. The default language
for django has been set to en-US.

If you request a page /registration/ with nl-NL as Accept-Language
header, I get a 404.
I wasn’t expecting such behaviour. Rather I was hoping I would be
redirected to /registratie/ ,the tranlated url that corresponds my
Accept-Language header.
Ofcourse /registratie/ with the nl-Nl Accept-Language header, works
fine and gives me the expected 200.

I’m guessing this is just as normal as it can get ?

Isn’t there a chance a user might get link from some website and
the link is build for the English language, but the user in question
has a different supported language setting, Accept-Language header ?
In such a case he would be presented with a 404.
He should be presented with or the English (default) content or
or be redirected to the correct url for his language if supported.

Also what happens if a user has a not supported language setting ?
Will the django default LANGUAGE_CODE be used, en-US in my case ?

Is there a way to work around this or handle it in a different better way ?

an extract from my urls.py file, shows how I’ve setup translated urls:

url(_(r'^step1/$'), AccountTypeSelectionView.as_view(), name="registration_step1"),

Answer 1

I’m making a wild assumption that _ is ugettext_lazy.

Also what happens if a user has a not supported language setting ? Will the django default LANGUAGE_CODE be used, en-US in my case ?

Yes, ugettext will use the default value if no specific value is set. You can see this behaviour in do_translate in django.utils.translation.trans_real.

What happens with ugettext_lazy is that just prior to the URL being looked up, it is translated to the user’s language and then the part of the URL is checked against all these. (Django uses a per-thread language setting that is changed to reflect the user’s choices.)

Isn’t there a chance a user might get link from some website and the link is build for the English language, but the user in question has a different supported language setting, Accept-Language header ? In such a case he would be presented with a 404. He should be presented with or the English (default) content or or be redirected to the correct url for his language if supported.

Well, yes I believe that should be a supported feature but a quick look at the source made it appear that URL resolving would have to be changed a bit to accomodate this.

What you can do, is use a custom 404 page (as briefly mentioned here under Customizing error views):

in your urls.py:

handler404 = 'mysite.views.i18n_retry'

and in a view

from django.utils.translation import override
from django.core.urlresolvers import resolve
def i18n_retry(request):
    for language in settings.LANGUAGES:
        with override(language, deactivate=True):
           try:
              result = resolve(request.path)
              #here you will know what language the url is in
              #if it is a supported format
              #and can do something smart about it
           except Http404:
              #Http404 is thrown whenever resolving fails
              pass
     #here you should probably return a real 404

I’ve used the override context manager from Django 1.4. but there is a longer way of doing the same without.