Hi, yes I think moving our stuff to a runtime bundle is the correct way. This would enable everybody to use the new message extension without knowing about the tools. It would also add the possibility to the platform to use this instead of the TranslationService (which is really not a good replacement for NLS) and even make it possible to replace NLS to finally add multiple locale support to Eclipse itself. IMHO this would help to evolve the Eclipse platform itself. Of course it is just a small enhancment regarding the whole platform, but definitely a place to start.
We haven't talked to the guys from RAP. I didn't even know that they support locale changes at runtime. Does RAP support the E4 application model and dependency injection? Because our solution is using ExtendenObjectSuppliers and dynamic injection to support locale changes at runtime. Greez, Dirk On Tue, Sep 3, 2013 at 3:38 PM, John Arthorne <[email protected]>wrote: > I agree leaving it in e4 repository is not the right long term home. You > interpreted the silence to Dirk's post to mean that nobody wants it. > Another way to interpret that is nobody objected so you can go ahead and > release it in a core runtime bundle. Of course the most likely answer is > that everybody was on holiday or busy and just missed it ;) > > So let's try Dirk's question again. Does anybody object to this work > moving into a core runtime bundle, such as org.eclipse.e4.core.services. In > my opinion the x-internal TranslationService we already have in > e4.core.services is not a good replacement for NLS, due to the runtime > overhead of having string keys. We also know that NLS lacks any way to > support multiple locales at runtime, or dynamic locale change at runtime. I > haven't had a chance to look at the implementation, but Dirk and Tom's > approach sounds promising to me. I would have no objection moving this into > a runtime bundle, perhaps still in x-internal / provisional form but in a > correct "final" bundle namespace so people can start using it. What does > everyone else think? > > I would also be curious whether the RAP folks have looked at this. They > are the experts in supporting multiple locales at runtime so I would be > curious to hear their input on that. Have you guys talked to them about > your approach? > > John > > > > > From: Tom Schindl <[email protected]> > To: [email protected], > Date: 09/03/2013 09:07 AM > Subject: Re: [e4-dev] Eclipse Internationalization with the new > message extension and the Eclipse translation pattern > Sent by: [email protected] > ------------------------------ > > > > Hi, > > The problem is that currently this whole stuff is the tools-namespace > and I think it is not very logical that something like this in tools > whereas it clearly is a runtime kind of thing. > > The same argument goes for the IResource stuff beside that the you'll > notice that there are also the bridge services e.g. for c&p, ... . > > I have no problem if the platform adopts this features (then we can > consume it from one of the e4 runtime bundles) but if it does not I > don't want to point my users (=efxclipse) to a perpetum incubator where > the stuff is found in an none intuitive namespace. > > Tom > > On 03.09.13 14:36, Lars Vogel wrote: > > Hi, > > > > If I understand your email correctly you are suggesting to move the > > current implementation to another Git repo. What is the problem with > > leaving it in the e4 tools repository? You have commit rights there and > > if Dirk want to work on it, we can also suggest him as e4 committer. > > > > Best regards, Lars > > > > > > 2013/9/3 Tom Schindl <[email protected] > > <mailto:[email protected] <[email protected]>>> > > > > Hi, > > > > From the lack of feedback it seems the platform is not really > interested > > in this feature. > > > > Still we - e(fx)clipse - would like to advertise this way of NLS to > our > > (e4) users. I talked to Dirk and he's no objections moving it to > > efxclipse-runtime where our core bundles only depend on e4-di (no fx > > involved). > > > > Anyone can make use of it no matter if they use e4+SWT, e4+FX, e4-di > > only, ... . Any objections? I think leaving it into e4 tools is the > > worst of the options. > > > > We will not remove the support from e4 tools but we could maybe > > deprecate it and point to the e(fx)clipse version? > > > > Tom > > > > On 12.08.13 11:20, Dirk Fauth wrote: > > > Hi everybody, > > > > > > I'm not sure if everybody is aware of the message extenstion that > was > > > created by Tom Schindl and extended by me. > > > > > > I would say it is an evolution of the existing internationalization > > > stuff in Eclipse, that introduces a lot more flexibility. > > > > > > Currently it is contributed to the e4.tools.services plugin, but > IMHO > > > this is the way internationalization should look like in future > > releases > > > of Eclipse. So it should be included into the platform itself. The > > > current code is a summary of workarounds that were necessary > > because of > > > missing features in Java 1.4. But with Java 1.6, these workarounds > can > > > be solved elegantly (loading of ResourceBundles). > > > > > > Using the new message extension it even becomes possible to change > the > > > locale at runtime, using OSGi services and the dynamic injection > > in E4. > > > > > > The last few months Tom and I worked on the solution, making it > > > flexible, configurable and stable. We also blogged about it. > > > > > > > > > http://blog.vogella.com/2013/05/03/eclipse-internationalization-part-14-current-situation-by-dirk-fauth/ > > > > > > We would like to see this solution in the Eclipse Platform itself. > So > > > with this mail we want to start the discussion if there is > > anything that > > > speaks against that. > > > > > > So please let us know what you think. > > > > > > Greez, > > > Dirk & Tom > > > > > > > > > _______________________________________________ > > > e4-dev mailing list > > > [email protected] <mailto:[email protected] <[email protected]> > > > > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > > > _______________________________________________ > > e4-dev mailing list > > [email protected] <mailto:[email protected] <[email protected]>> > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > > > > > > _______________________________________________ > > e4-dev mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
