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.
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
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
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
I have a website with the following i18n requirements:
Part of the site is monolingual with conventional URLs (e.g. /first/
example/).
Another part of the site is multi-lingual content from the database
(flatpages-like). The language code should be accepted as a prefix in
the URL (e.g. /fi/s
5 matches
Mail list logo
