A followup to my previous message: I have made a Django application that gets the language from the URL. It is located at: http://www.cassee.org/trac/wiki/LocaleUrl
To enable, add locale_url.middleware.LocaleUrlMiddleware to settings.py and add locale_url to the applications list to enable the template tags and filters. Add the i18n context processor. Adding the request context processor is also advised to give template tags access to the request.
The app support the following functionality: * Paths like '/nl/admin/' are rewritten to '/admin/', so urls.py does not have to be changed. * Paths without locale are redirected to the default locale (from settings.LANGUAGE_CODE) or a previous language discovery middleware. * settings.LANGUAGE_INDEPENDENT_PATHS is a tuple of regular expressions of paths that should not be redirected. Also MEDIA_URL is not redirected. * urlresolvers.reverse is monkey patched to return paths with locale. * 'locale_url' template tag to render a path in HTML (like the 'url' tag, but with locale info): {% locale_url "nl" app.views.view arg=value %}, or {% locale_url "de" %} for the current page in a different language.
Bugs: * The 'reverse' patch does not take LANGUAGE_INDEPENDENT_PATHS into account (will be fixed soon). * Admin (in newforms-admin at least) does not use the 'url' tag, but its own 'app_path' variable. This breaks login. Override 'admin/login.html' and change the form action URL as follows:
I known this is all still a bit rough. Still, I hope some of you find it useful. Comments and discussion on design and implementation are very welcome.
On Fri, May 30, 2008 at 5:13 PM, Joost Cassee <cas...@gmail.com> wrote:
> Hi all,
> A followup to my previous message: I have made a Django application that > gets the language from the URL. It is located at: > http://www.cassee.org/trac/wiki/LocaleUrl
> To enable, add locale_url.middleware.LocaleUrlMiddleware to settings.py > and add locale_url to the applications list to enable the template tags > and filters. Add the i18n context processor. Adding the request context > processor is also advised to give template tags access to the request.
> The app support the following functionality: > * Paths like '/nl/admin/' are rewritten to '/admin/', so urls.py does > not have to be changed. > * Paths without locale are redirected to the default locale (from > settings.LANGUAGE_CODE) or a previous language discovery middleware. > * settings.LANGUAGE_INDEPENDENT_PATHS is a tuple of regular expressions > of paths that should not be redirected. Also MEDIA_URL is not redirected. > * urlresolvers.reverse is monkey patched to return paths with locale. > * 'locale_url' template tag to render a path in HTML (like the 'url' > tag, but with locale info): {% locale_url "nl" app.views.view arg=value > %}, or {% locale_url "de" %} for the current page in a different language.
> Bugs: > * The 'reverse' patch does not take LANGUAGE_INDEPENDENT_PATHS into > account (will be fixed soon). > * Admin (in newforms-admin at least) does not use the 'url' tag, but its > own 'app_path' variable. This breaks login. Override 'admin/login.html' > and change the form action URL as follows:
> I known this is all still a bit rough. Still, I hope some of you find it > useful. Comments and discussion on design and implementation are very > welcome.
<panos.lagana...@gmail.com> wrote: > Ah, seems we're getting somewhere with this :)
> I'll look into it, thanks for posting it.
> On Fri, May 30, 2008 at 5:13 PM, Joost Cassee <cas...@gmail.com> wrote:
>> Hi all,
>> A followup to my previous message: I have made a Django application that >> gets the language from the URL. It is located at: >> http://www.cassee.org/trac/wiki/LocaleUrl
>> To enable, add locale_url.middleware.LocaleUrlMiddleware to settings.py >> and add locale_url to the applications list to enable the template tags >> and filters. Add the i18n context processor. Adding the request context >> processor is also advised to give template tags access to the request.
>> The app support the following functionality: >> * Paths like '/nl/admin/' are rewritten to '/admin/', so urls.py does >> not have to be changed. >> * Paths without locale are redirected to the default locale (from >> settings.LANGUAGE_CODE) or a previous language discovery middleware. >> * settings.LANGUAGE_INDEPENDENT_PATHS is a tuple of regular expressions >> of paths that should not be redirected. Also MEDIA_URL is not redirected. >> * urlresolvers.reverse is monkey patched to return paths with locale. >> * 'locale_url' template tag to render a path in HTML (like the 'url' >> tag, but with locale info): {% locale_url "nl" app.views.view arg=value >> %}, or {% locale_url "de" %} for the current page in a different language.
>> Bugs: >> * The 'reverse' patch does not take LANGUAGE_INDEPENDENT_PATHS into >> account (will be fixed soon). >> * Admin (in newforms-admin at least) does not use the 'url' tag, but its >> own 'app_path' variable. This breaks login. Override 'admin/login.html' >> and change the form action URL as follows:
>> I known this is all still a bit rough. Still, I hope some of you find it >> useful. Comments and discussion on design and implementation are very >> welcome.
> Most people (if not all), who use DM, would want to use this app too. > Plus it'll get much closer testing there.
I agree that it is a good match. The idea of having the language on the URL has also seen the most discussion on this list. On the other hand it is definitely functionality that can stand on its own. I like having small independent apps. You might call it the UNIX school of Django. :-)
It is not that I am adverse to having it in the same repo, it's just that setting up a Google Code project is so easy that the overhead of having it in its own place is negligible.
> Any ideas how to resolve the `reverse` issue yet? :)
That issue has been fixed. I now replace the reverse function on one of my own if the middleware is installed.
The only problem left is the fact that the admin interface does not use the standard Django standard of generating URLS using reverse and the url tag. Maybe I should just special-case the admin?
