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/Internationalisation On Mar 29, 6:44 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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 > inhttp://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 > > (seehttp://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 -~----------~----~----~----~------~----~------~--~---
