Hi, Django-localeurl does something like this. I've successfully implemented it in several projects.
http://bitbucket.org/carljm/django-localeurl/ http://pypi.python.org/pypi/django-localeurl/1.4 Benoit Clennett-Sirois On Mon, Oct 25, 2010 at 8:54 AM, Oliver Beattie <oli...@obeattie.com> wrote: > Hi all, > > I have a bit of an conundrum for you that I'm a little stumped with… > I'm wondering whether I'm missing something painfully simple in my > search of rather complicated options. Basically, I need a prefix on > all URLs (for instance /uk/ or /us/), but I don't want each and every > view to have to accept it as a parameter. reverse_url et all would > still need to work, and I would still need to be able to redirect > users not using this prefix (links to existing URLs) to the new format > based on GeoIP [currently in use but again using separate domains]. > Most of the url resolution functions have been wrapped in some custom > code anyway (so I can pass an optional country_code parameter to the > reverse function if desired), so it's not really a big deal if the > code of these needs changing. > > Disclaimer: I don't want to monkey patch anything. Demanding, ain't I? > > I initially thought this would be possible with the use of > process_view middleware, and this is still probably my best option, > but it's still not really all that nice, since I'd need to call > view_func directly with the modified argument list — and that looks > like it would render exception middleware unusable. > > Currently, the system is set up to do this with a different domain > (domain.co.uk, domain.com.au etc), and then some process_request > middleware sets a COUNTRY_CODE variable on the request, and this is > something I'd like to continue using as a substantial codebase > (hundreds of views) already relies on this. There is a whole framework > we have built around localizing various things depending on this > variable. > > Other things I thought of and have since discounted after looking at > their code are:- > > * A custom request handler that can deal with this (would require > quite a bit of code duplication for a small amount of change, due to > the length of the BaseHandler.get_response function) > * A custom URL resolver/urlpatterns that can do what it will with the > parameters, but I don't think that's possible > > I did also think it may also be possible with WSGI middleware, but I > don't really know where I might start with that. > > To me it seems the only way to really go about this (in Django) is to > wrap each and every view in a decorator… which just feels extremely > messy. And even then I doubt all the thousands of existing calls to > reverse_url would work without modification. > > I think in writing this I've almost convinced myself the best way to > go about this is to convince the powers that be to let it be a > subdomain like many other sites rather than a subdirectory… but if > anyone has any ideas I'd love to hear them. > > Like I said, I'm really hoping I've missed something obvious :) Any > help would be really appreciated. > > —Oliver > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
