Re: Language code as part of URL

Panos, Thanks for the links. I checked the conversation and the blog post, by they address issues I've already solved. What I'm really struggling with is the reverse() problem and how to cleanly move the language activation logic from middleware (Django's default mechanism) to the URL resolver.

Re: Language code as part of URL

Andrew, Thanks for your thoughts! > If the content is ultimately the same and you're simply offering > translations you don't want to put the language code before the > resource in the URL. Ie you don't want /fi/second/example/ because the > hierarchy implies that for a different country it's ac

Re: Language code as part of URL

We had some discussion about this on django-multilingual. Take a look here: http://groups.google.com/group/django-multilingual/browse_thread/thread/c394d3aed317a19a/b25464fa1f2aea4e#b25464fa1f2aea4e and yml's implementation (which is actually usuable): http://yml-blog.blogspot.com/search/label/I

Re: Language code as part of URL

This isn't an answer to your technical query but rather some thoughts on how to do localisation in URLs. Localisation in URLs is tricky because the best way to do it varies enormously depending on the nature of your localisation. If the content is ultimately the same and you're simply offering t