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 -~----------~----~----~----~------~----~------~--~---