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:

##################
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

On 4/5/06, atlithorn <atlith...@gmail.com> wrote:

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

I understand how django does it. Unfortunately I am forced to maintain
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.

On 5 Apr 2006, at 12:26, limodou wrote:

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

Op wo, 05-04-2006 te 16:34 +0100, schreef Simon Willison:

Or sometimes using a cookie...

[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

I very much agree with Simon and Jan. A middleware like this would be
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.

I would like to add another good reason: Another nice effect language
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

Glad I am not alone :) There is a little irritation in using the
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.

On 4/5/06, Simon Willison <swilli...@gmail.com> wrote:

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

--
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

Optional middleware seems okay, or perhaps we can just set up a
wiki-page on the Django site about this so everybody can implement this
their own way.

Rudolph

A downside in this is increased complexity when generating links
between pages.

2006/4/5, Rudolph <rudolph.fro...@gmail.com>:

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

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:

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

2006/5/19, jon1012 <jonathan.schem...@gmail.com>:

Thanks for your function, that's not exactly what I need but it's really
interesting.