Correction: in all places where I used T.force = True, I meant T.lazy = False
On Nov 6, 11:25 am, Kevin <[email protected]> wrote: > 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.
