[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [babel-dev] The Runtime Translation Editor
|
Title: Message
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
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=262111
It 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
