Kevin Dangoor <[EMAIL PROTECTED]> writes: > On 1/13/06, Jorge Godoy <[EMAIL PROTECTED]> wrote: >> I'll try and see if I can come up with this >> cherrypy.request.calendar_language >> thing. I can't guarantee it will be today -- I'm travelling and I'll be back >> on Tuesday --, so don't hold your breath for now. But I'll get it working >> soon. ;-) > > The general philosophy is to try to get it right 90% of the time, and > then provide a way to override if the API user isn't happy with what > they're getting those other 10%. See how it works for you (it's > especially handy that your particular need has one of the edge cases). > > And, don't worry, I won't hold my breath. I'm chasing after enough > different things right now that I need all the air I can get :)
So, here it is... I've tried it and it works for me. I believe that for people using 'en' in their browsers and that don't pass any of the new attributes everything will be the same. http://trac.turbogears.org/turbogears/ticket/411 I've opted to use turbogears.i18n.utils.get_locale() to set the default language. If it doesn't work -- i.e., the JS file doesn't exist --, passing 'lang' will solve that. Kevin, I dunno if you'll accept the move of the javascript attribute from outside to inside the __init__() method, but that was the only way I could think to override the language here without adding too much code or making things worse. Be seeing you, -- Jorge Godoy <[EMAIL PROTECTED]>
