Hi Evgeny,
On Apr 29, 6:44 pm, Evgeny <
evgeny.fad...@gmail.com> wrote:
> Hello, I have a very odd issue with this application.
Which application? This lists supports several... I presume django-
localeurl since you mention "patched reverse," but I'm not sure
localeurl alone can explain the symptoms you are seeing. Are you also
using an app to manage translated database content (django-
multilingual, django-modeltranslation, transmeta...)?
> For a while things are fine, but at some point url translations
> magically change and site shows many 404 errors.
In general, this sounds like a problem related to import race
conditions. In development (using runserver) Django validates models
at startup, so all models.py files are imported before any requests
are served. In many production setups (mod_wsgi is the one I'm
familiar with) this is not the case, and if monkeypatching or other
import-time side-effects happens in an app's models.py file, it may
not be imported early enough for the monkeypatching to properly take
effect. Or it may get imported soon enough in one webserver process,
but not in another, which can explain intermittent effects, depending
which process serves a given request.
> As a result I see the site in English, but all urls in Turkish and
> when I switch to other locale's url's are persistently translated to
> Turkish.
I'm not clear on this particular symptom (in particular I'm confused
about what you mean by "translated urls," as django-localeurl doesn't
out-of-the-box support actual translation of URLs, it just prefixes
them with a language code). But my guess is that the solution will
involve ensuring that localeurl's models.py (and/or possibly the
models.py of whatever content-translation app you use?) get imported
before any requests are served. An import from your root urlconf is
perhaps the easiest way to take care of this, though kind of ugly.
> On a separate note - I had to hack my application in one place - had
> to explicity import your patched "reverse" otherwise reverse in
> get_absolute_url would not work.
Yes; this is actually the same root issue, I think. By importing
reverse from localeurl, you just ensure that the monkeypatch actually
happens soon enough.
I need to add some documentation to this, and/or (the ideal) find a
way to fix localeurl so it doesn't require a monkeypatch. There's an
issue filed:
http://bitbucket.org/carljm/django-localeurl/issue/5/reverse-not-patched-on-apache-mod_wsgi
Patches welcome ;-)
I also consider it somewhat of a bug in Django that this can happen so
easily; Django's architecture encourages import-time side-effects
(with all the metaclass/registration patterns, signals, etc), and it
would be preferable if Django did a bit more to ensure that runserver
startup and production startup imported things in similar orders, to
prevent this sort of mysterious bug. I hope to bring up this issue
sometime in the 1.3 cycle.
Carl