On Jun 10, 2007, at 7:53 PM, Diez B. Roggisch wrote:
>> I've tried it out in a freshly quickstarted app (attached at the
>> ticket) and looks great. These are the steps I took in case anyone
>> wants to try it out:
>> 1) tg-admin quickstart
>> 2) wrote a sample and dumb helloworld.js at ${package}/static/
>> javascript and placed a button at welcome.kid to trigger the
>> function.
>> 3) registered that directory with widgets.register_statict_directory
>> 4) set tg.include_widget = ["turbogears.jsi18nwidget"] in app.cfg
>> 5) tg-admin collect
>> 6) generated po in the toolbox
>> 7) tg-admin compile
>> 8) start app and enjoy
>> Some comments & suggestions:
>> 1) It took me some time to figure out 3. Couldn't the widget or
>> something be more clever and do this automatically. I guess it's kind
>> of unintuitive for those not using widgets to include their js files
>> at the template. Maybe the i18n widget should be just an
>> implementation detail and this functionallity work for those not
>> using widgets at all.
> I'm not sure I understand what you want here. I _do_ understand
> that the
> registration step can be done - I just did it in my testing-app that
> first didn't have any code in TG itself, so I just missed that things
> don't work without it. I just added the necessary code and it works, I
> replaced the patch in the trac.
> What I don't understand is the rest. Everybody is free to include
> js-files herself, but then she is on his/her own.
I think that all is needed is to register the project/static/
javascript so the messages-X.js file can be served.... Hmm, I see
that your latest patch does this... cool.
>> 2) Do you have plans to make this useful for distributing 18n bundles
>> with packaged widgets? From the code I guess messages-X.js must live
>> inside a TG app but I might be wrong...
> So far it has to live there, yes. I currently don't use packaged
> widgets, but I can see it would be helpful to have this functionality
> there.
> The collect/merge/create-js-stuff should work the same way.
> What is missing is the inclusion of the message-files with another
> package-name - the packaged widget one.
> I can thing of one of several ways to accomplish this. One would be to
> factorize out the JSLink-creation facilities of the JSI18NWidget,
> giving
> a packaged widget author a way to create the links with her own
> package
> name as argument.
> The other one would be a static registration of package names. Benefit
> of the first approach: the amount of js-files included in each
> template
> is reduced. Benefit of the second approach: the author has less to
> write.
Hmm, whatever you think it's best I think too since I'm not very much
into the details of your patch's code. However, the "the author has
less to write" part sounds appealing... :) Maybe a future improvement
of TG-Widgets/TW could be to concatenate, jsminify and gzip all js
files into a single file to optimize load time so having many js
files isn't too problematic after all.
> Either or even both options could be included - but I need to get on
> speed with packaged widgets, which I'm currently not - so I'm open for
> help here. Well, I'm open for help in any case :)
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 :)
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)
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)
Alberto
