> tg-admin quickstart -t tgwidget MyWidget > > creates a bare-bones widget package. There's really not much more > into it... just keep in mind the neccesary entry point for the > toolbox to load them for the widget browser. > > I can't help much more since my TG-widgets-foo is pretty rusty now > since I've been using TW since it was born :)
I created a new patch, and introduced the following functionality: The widget now has a property, locale_catalog_providers. This is a list of callables that are invoked with the current locale. They have to return a list of JSLinks or similar resources. Then there is a method, register_package_provider, that takes a package name, a directory path relative to that package, and a domain. These default to the current app's package, 'static/javascript' and the configured i18n.domain or 'messages'. The widget will by default register a package-provider that delivers js-catalogs as before, but this can be configure away by setting i18n.suppress_default_package_provider = True in the app.cfg. This scheme allows widget-authors now as well to register their respective packages & static javascript-dirs, or even come up with a totally new scheme. > BTW, I finally implemented JS i18n with a similar approach as yours > in the (pylons) app I talked about so thanks for the inspiration :) > Some thinks I found which you might want to consider as ideas for the > patch: > > 1) pygettext.py can extract localizable strings from JS files. I'm > not sure how robust this would be in the long run or the degree of > "hackiness" it achieves, but it's certainly easier than the regexps > (however, now that they're already implemented I see no good reason > to change them) I will look into it, as my current implementation works but lacks e.g. multiline-support. > > 2) A gettext.translations instance has a private attribute called > "_catalog" which is a dict with the translation mapping once the What > I did to create the translation mapping for the JS side is something > like: > import gettext > t = gettext.translation(domain, localedir, [langs]) > js_mapping = "var MESSAGES = %s;" % simplejson.dumps(t._catalog) > > and then serve this dynamically from a controller method (no need to > maintain the js files but certainly not as efficient) I won't use this myself - but with the new functionality above + the config-option, you (or someone) are free to implement that yourself if you like, because the locale_catalog_provider concepts allows for that. Hope this new scheme is flexible enough for most of the needs. The only thing the current concept lacks is a way to deliver js based on page-based context. By that I mean that if e.g. the application contains 20 js files that are i18n'ed, the messages will always be delivere fully, regardless of the actual usage of only a subset of the js-files. However, I don't consider this a major drawback - at least in my usage scenarios, there are only a few i18n'ed messages in JS anyway, for e.g. creating links or buttons. Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
