Questioning our use of LazyProxy in trac.util.translation
Christian Boos
While working on http://trac.edgewall.org/ticket/9699 (TypeError:
sequence item 0: expected string, LazyProxy found), and in particular
when experimenting with disabling the LazyProxys entirely, I realized I
was not even able to trigger a LazyProxy to be used. As Remy wrote in
that ticket, it seems no gettext call is ever made before the
make_activable() call in dispatch_request() (see
http://trac.edgewall.org/browser/tags/trac-0.12.1/trac/web/main.py?marks=477#L475).
As a reminder, here's our typical use of LazyProxy:
http://trac.edgewall.org/browser/tags/trac-0.12.1/trac/util/translation.py?marks=188-189#L185
It seems that we only end up using those when no translations are
available for one reason or another (#9699), in which case delaying the
translation is of no use. So I'm tempted to remove those LazyProxy
wrappers altogether. I simply fear I'm overlooking something, that's why
I'm asking here, in case anyone remembers what they were for ;-)
The only corner case is at server startup, for the very initial
unpacking of the catalog files, which doesn't seem to always work when
there are concurrent requests (ExtractionErrors). This is just at init
time, so the only harm would be at most a handful of untranslated
responses, trying to avoid this exceptional case alone doesn't justify
the trouble induced by the use of LazyProxies.
-- Christian