CODEWITHSUNDEEP
djangolocalizationtranslation
Jonas Geiregat
Jonas Geiregat

Reputation: 5442

django translated urls and accept-language header

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

Upvotes: 2

Views: 1425

Answers (1)

Jyrsa
Jyrsa

Reputation: 438

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.

Upvotes: 2

Related Questions