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 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 in http://tools.ietf.org/html/rfc3986#page-23). This says to users that they're viewing the same resource but in a different language. If the content of a whole section of the site is actually different (ie not just a translation) depending on country then using a country path segment in the URL is fine. An example use case would be the Apple Store where the product range and information are actually different in different countries. This article discusses localisation in URLs in more details: http://h3h.net/2007/01/designing-urls-for-multilingual-web-sites/ Regards, Andrew Ingram akaihola wrote: > 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/second/example/). > > Links generated with {% url %} and reverse() should retain the > language prefix. > > Multi-lingual content is editable by authorized users. > > If a URL for a multi-lingual page is requested but the language code > is missing, a redirect is done according to the visitor's active > language (e.g. /second/example/ -> /fi/second/example/). > > When editing multi-lingual pages in any language, the editing user > interface stays always in one language chosen by the user (e.g. UI in > German when editing content in German, Swedish or English). > > If the requested multi-lingual page hasn't been translated to the > visitor's current language, a redirect is done to an existing > translation (according to browser preferences or site's default > language). But navigation and other links to other pages should point > back to URLs with the originally requested language. > > In the links for viewing pages in another language, the language > names should be in the language itself (see > http://code.djangoproject.com/ticket/4030). > > > We have most of this functionality implemented and working, but the > code is rather involved. I'd like to create clean, re-usable modules > instead. > > I'm currently out of ideas for how to design the language code URL > prefix handling as a drop-in module for use with any views which > utilize Django's standard i18n infrastructure. The troublesome point > is how to keep the language code prefix when using {% url %} / > reverse() without having to modify the views. > > It's simple to use either middleware or a decorator to catch the > language code prefix, activate the correct language and strip the > language variable from being passed on to the view. I'm leaning on the > decorator side since part of the site doesn't use the prefix. > > Currently I have a customized url() function for creating language- > prefixed urlpattern rules. It returns a subclassed RegexURLPattern or > RegexURLResolver which modifies the regex to catch the language > prefix. Views are wrapped in a decorator which consumes the prefix and > activates the correct language. > > The problem is that since the language prefix catcher is now part of > the regex, I can't use reverse() in the view or {% url %} in the > template without modifying views/templates to pass the current > language explicitly as a kwarg. That's goodbye to drop-in style re- > usability. > > The way reverse() is implemented makes it difficult to inject the > value of get_language() back into the URL. I doubt that the required > changes will be accepted in Django. > > > Maybe there's an easy solution I just can't see now. Also, if anyone > has similar requirements as described above, it would be fruitful to > share thoughts and code. If we manage to create re-usable components > with no pre-existing counterparts, we'll of course publish and > maintain them. > > > I've collected some relevant links here: > http://www.diigo.com/user/akaihola/django+language-in-url > > > -Antti --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
