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