Ooh, great! That can be one of the harder parts coming into bells-and- whistles framework -- on the one hand the learning curve is very shallow, but on the other hand, you might start out reinventing a wheel that the framework already has. One of the most unique things about web2py is definitely the lightning fast community support.
Thanks! On Nov 6, 1:22 pm, mdipierro <[email protected]> wrote: > You can do > > mydate.strftime(T('%B %d, %Y').xml()) > > On Nov 6, 12:25 pm, 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. > >
