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 actually a > different object. My preferred approach for translations is /second/ > example,fi/ (comma seperated as outlined > inhttp://tools.ietf.org/html/rfc3986#page-23). > This says to users that they're viewing the same resource but in a > different language. I've previously read and understood the reasoning behind the comma approach. At that time I still chose the language code as URL prefix, mainly because I felt it offers better usability and clearer URLs. For my eyes the ,fi suffix resembles the annoying .php? foo=bar&id=123672436 cruft still seen on many sites. But I acknowledge that there's a problem in the hierarchy logic. Anyway, the comma suffix approach doesn't fit well with Django's stock language handling, either. Django assumes the language is set and stored in the session in a separate view, which redirects back to actual content. When the language code is part of the URL, no redirection is done and the language is set as part of URL parsing. It could be done in a middleware, but I don't like that approach since middleware is unaware of the URL hierarchy and differences in language code handling between parts of the hierarchy. I'll take a look at the discussion Panos pointed out and see if any silver bullets are presented there. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
