| Re: [babel-dev] The Runtime Translation Editor |
Sean has it absolutely right when he says that instant translations do require quite a lot of co-operation from the plug-in. This is the one point that has made it difficult to progress this work. I had been assuming that if we can get it to work and get a few adopters, albeit with some fairly kludgy code such as that early start-up stuff, then we would have a better chance of getting the changes we would need in the core Eclipse and SWT code to support this more cleanly. I appreciate the feedback from Sean, that is helpful.By the way, I have been on forced inactivity due to legal issues with my new major employer. However these were resolved last week and I believe my committer rights have been restored by the Foundation's lawyers so I will be thinking about the next step in progressing the Babel runtime plug-in. I also want to get the two IDE contributions unified. This is something I was hoping to do for 3.5, but I am concerned we may be too late for that now.
Nigel Westbury-----Original Message-----
From: babel-dev-bounces@xxxxxxxxxxx [mailto:babel-dev-bounces@xxxxxxxxxxx] On Behalf Of Antoine Toulme
Sent: Thursday, January 22, 2009 8:51 PM
To: Babel committers mailing list
Subject: Re: [babel-dev] The Runtime Translation Editor
On Fri, Jan 23, 2009 at 1:56 AM, Sean Flanigan <sflaniga@xxxxxxxxxx> wrote:
I've been trying it out from CVS. It looks good. Running under
Ganymede-SR1/Java5, the RTE was able to translate itself using the
Translate This Dialog button (since it uses the class TranslatableNLS),
but it wasn't able to find any of Eclipse's menus. Perhaps the
menu-parsing needs to be updated for Eclipse 3.4, or maybe it's the
Java5/Java6 issue? Any ideas?
Also, I'm getting lots of Unhandled event loop exceptions (NPE) in my
Error Log, but I should put in a bug for that.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=262111It looks like the menu problem and your NPEs are related.
It was impressive to see instant translation updates, but it seems to
require a lot of co-operation from plugins which want to be translated
(ie using classes like TranslatableNLS, TranslatableSet,
TranslatableText). And consider how hard it is to get projects just to
externalise their strings!
Now, I suppose instant translation updates do require co-operation from
the plugin (or perhaps invasive AOP). At the moment, unco-operative
plugins can only be translated if you know the plugin ID. And you have
to restart the entire application to see the new translations.
What might help:
1. Some sort of automatic mapping from GUI component to plugin/resource
bundle. SWT must know, at least in some cases:
http://markmail.org/message/jjnmxme4kq4qfhrw
2. Plugin reloading/reactivation to pick up new translations. OSGi can
stop and start bundles, can't it? (Obviously, you can't reload all
plugins, but surely some of them could be restarted.)It can. If you start eclipse with the -console argument, you then can do:
start org.xyz.hello
stop org.xyz.hello
And so on.
Plugins which use TranslatableNLS would still have instant translations,
but this should improve the situation for the other plugins.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev