Kevin Dangoor <[EMAIL PROTECTED]> writes: > You *could* do something like set cherrypy.request.calendar_language which > then reflects what gets included. I'd advocate *trying* to guess the > language to use if nothing is set there and using that if there is something > set.
How would I try to guess in the case I've shown where I have both: calendar-pt-utf8.js and calendar-pt.js? Guessing the 'pt' part should be OK but how about choosing the UTF8 version or not? I'll see what CherryPy receives related to encoding. Since it's debug is enabled for this 2.2.0 beta, it shouldn't be that hard. Maybe if there's 'utf-8' there then we enable the UTF8 version, otherwise the simple one. There's a third type: calendar-cs and calendar-ru have a 'win' encoding, so we have three cases: plain calendar, utf-8 encoded and these two win encoded. > If we do go the cherrypy.request.calendar_language route, that would > help ensure that only one language JS is included. I believe it is good for most cases. If somebody needs more than one language on the same page, they can make a new patch later ;-) 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. ;-) Be seeing you, -- Jorge Godoy <[EMAIL PROTECTED]>
