Kevin Dangoor <[EMAIL PROTECTED]> writes: > Ahh. You may need to override the function that produces the set of > JavaScripts for the widget. > > Remember that, at least at present, widgets are stateless. It seems > like when the javascript is requested, at that point you could look up > the locale and return the appropriate language pack.
Since calendar languages are different from what we have from the browser or with cherrypy I thought about adding a new variable -- defaulting to 'en' -- to choose the language. For example, there are two options for pt: pt and pt-utf8. One would never get 'pt-utf8' automatically (and that would be my choice to use, since it is "more correct" Portuguese). I am thinking on how to override that, though... Probably setting a variable before the JSLink and putting some way to override it in __init__(). This way, if nothing is changed, English is still used and one can then send whatever value exists at turbogears.widgets/static/lang/calendar-<value>.js to be used instead... What do you think? If you agree, I can change it, test, and send you a patch. I just don't know what would happen if there are two (or more) different calendars with two different languages on the same page (probably there will be one instance of each JS and I don't know if they'll clash and if they don't then the expected -- one calendar on each language -- behaviour would probably be achieved...) but I'd consider that a bug, though... -- Jorge Godoy <[EMAIL PROTECTED]>
