Locale from URL Middleware
atlithorn
support selecting languages from the URL itself. eg:
www.example.com - default english
www.example.com/de - same page with german trans
It was a simple copy-paste of the LocaleMiddleWare from the distro:
##################
from django.utils.cache import patch_vary_headers
from django.utils import translation
class LocaleURLMiddleware:
def get_language_from_request (self,request):
from django.conf import settings
import re
supported = dict(settings.LANGUAGES)
lang = settings.LANGUAGE_CODE[:2]
check = re.match(r"/(\w\w)/.*", request.path)
if check is not None:
t = check.group(1)
if t in supported:
lang = t
return lang
def process_request(self, request):
language = self.get_language_from_request(request)
translation.activate(language)
request.LANGUAGE_CODE = translation.get_language()
def process_response(self, request, response):
patch_vary_headers(response, ('Accept-Language',))
translation.deactivate()
return response
limodou
>
> Just in case anyone is interested... I wrote my own middleware class to
> support selecting languages from the URL itself. eg:
>
> www.example.com - default english
> www.example.com/de - same page with german trans
>
> It was a simple copy-paste of the LocaleMiddleWare from the distro:
>
Why you need do this? Because django can auto judge the language from
your browser request http head, or context settings, or settings. If
you like , you can provide a language selection in web page, and
that's enough. The url doesnot need to be special processed I think.
--
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit
atlithorn
a web structure that requires this functionality so that's why I wrote
it. But I actually prefer this over the ambiguity in the browser
settings which most people do not set anyway and the extra step
required to select the right language if someone sends you a url that
ends up in the wrong language.
Simon Willison
> Why you need do this? Because django can auto judge the language from
> your browser request http head, or context settings, or settings. If
> you like , you can provide a language selection in web page, and
> that's enough. The url doesnot need to be special processed I think.
I for one much prefer the language to be specified in the URL rather
than being derived from the browser settings. I would prefer this
behaviour to be supported (at least as an option) in Django core. I
know that language detection based on browser HTTP headers is a
feature of the HTTP specification, but personally I believe that it's
a mistake in the spec. Here's my reasoning:
1. Serving up content from the same URL in a different language
depending on browser settings is an idea that is based on the ideal
situation where each translation is a perfect representation of the
content's underlying meaning. This is clearly not a realistic
proposition. Some languages have phrases that do not perfectly
translate to other languages, and translations may not be perfect in
any case due to human error. The French version of a page is
fundamentally different from the English version, and I believe that
the URL should reflect that.
2. Passing URLs around. If I copy and paste the URL of a page and
send it to a friend / post it to my weblog, my expectation is that
they will see exactly what I see. Likewise, if I quote something and
cite the original URL, my expectation is that I'm pointing back to
the source of that quote. Changing the content based on the language
header breaks that expectation. Again, I know it's part of the HTTP
spec - but it's so rarely implemented that very few users expect it
to happen.
3. Related to the above: What if I spot a typo in a page and want to
report it to the site owner? Sending them the URL is no longer enough
- I have to tell them my browser's language setting as well.
Given the above, I much prefer the approach taken by most sites that
feature content in multiple languages where the language code is
included somewhere in the URL.
That's not to say that the user's browser language setting should be
ignored - you can use it to inform them that the page is available in
their preferred language (maybe with a nice big note at the top of
the page, written in their native language of course).
Tim Berners-Lee and the W3C may disagree with me on this one, but I'm
convinced that using URLs to distinguish between languages is smarter
than relying on browser settings alone.
Cheers,
Simon
Jan Claeys
> I for one much prefer the language to be specified in the URL
Or sometimes using a cookie...
> rather
> than being derived from the browser settings. I would prefer this
> behaviour to be supported (at least as an option) in Django core. I
> know that language detection based on browser HTTP headers is a
> feature of the HTTP specification, but personally I believe that it's
> a mistake in the spec. Here's my reasoning:
[snip 3 good reasons]
One more reason is when you are using someone else's computer and you
don't prefer the same language as the owner. (That owner might also be
a "cybercafé" or such.)
--
Jan Claeys
akaihola
nice to have in django.contrib.
One useful enhancement would be the ability to specify in where in the
URL the language can be specified. On one of my sites the syntax of the
URL is always /userid/locale/page... so it would be safest to have the
middleware only accept locale codes from the second part of the URL.
Rudolph
codes in the URL is that search engine crawlers can easily get all your
content.
My customers often want something like this:
www.example.com -> site in the main language of your visitors
www.example.nl -> site in Dutch
www.example.com/nl-nl/ -> site in Dutch
etc.
I would highly appreciate such middleware.
Rudolph
atlithorn
middleware posted above because I obviously have to account for the
language in all lines in my urls.py (r'(\w\w/)?... and so on). I would
prefer for this to have the same result as using an "include"
statement, ie the prefix would be cut off. Going to look into that
tomorrow, if anyone knows where to look, a finger in the right
direction would be well appreciated.
limodou
The reasons are good enough. And I think these things are more
concerned with application. Maybe someone doesn't need it I think, or
current status in django is enough.
If you want to implement it, I can give my opinion.Firstly it should
be optional. Secondly, I also think maybe we need to resolve the apps
prefix first. Because how to design the url. Just set the locale
string after domain?
http://domain.com/en
http://domain.com/zh_CN
Or permit user set it every where he want?
http://domain/page/en
http://domain/page/zh_CN
Rudolph
wiki-page on the Django site about this so everybody can implement this
their own way.
Rudolph
akaihola
between pages.
David Larlet
Hi!
I'm really interested in this option (domain-name extension -> appropriate language), is it possible to have more details in implementation?
I'm a beginner in django so maybe I haven't look at the right place, feel free to answer with a simple link.
Cheers,
David
jon1012
current url and return it... Usefull to make a language change button..
All you have to do is to make a link to the url with '/fr' for example
in front of the value given by the function:
from django.conf import settings
def get_absolute_path_without_lang(request):
for lang in settings.LANGUAGES:
if '/' + str(lang[0]) + '/' in request.path:
return request.path.replace('/' + str(lang[0]) + '/', '/')
return request.path
David Larlet
I've done an helper function that strips the selected language from the
current url and return it... Usefull to make a language change button..
All you have to do is to make a link to the url with '/fr' for example
in front of the value given by the function:
Thanks for your function, that's not exactly what I need but it's really interesting.