I was designing a site today, and ran into some of the same
international date issues as other users, though I tried to do
something like:
mydate.strftime(T('%B %d, %Y'))
Suffice it to say, I quickly found out about T.force.
I do appreciate the reasons for doing lazy translations, though in any
app, I don't tend to appreciate the need for manual state tracking. I
think that in all cases, developers will be benefited by having one-
time keyword arguments available to do the equivalent of the global
setting. In other words, mydate.strftime(T('%B %d, %Y', force=True))
is a lot nicer than
{{T.force = True}}{{=mydate.strftime(T('%B %d, %Y'))}}{{T.force =
False}}
for a number of reasons, including issues relating to exception
handling.
For that matter, though, it seems like that since the whole stack is
controlled by web2py in normal cases, lazy vs eager translation can be
inferred -- if a T instance has its __str__ method called, then do
eager evaluation. Otherwise, in the common case (such as web2py
templating), it will be recognized as a T instance, and translation
won't be done until the render pass.
In any case, we have the option of ignoring libc issues entirely, and
reimplementing locales, timezones, and other global settings, as a
pure python, thread safe (perhaps as context handlers, usable with the
'with' statement) libraries. At this point, libc is in many ways a
deficit for the web community, and was never designed to handle cases
where these global settings would be changed frequently (if at all)
during runtime.
