+1
On Wed, Sep 4, 2013 at 10:58 AM, Lars Vogel <[email protected]> wrote: > 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? > > +1 from me > > > 2013/9/3 John Arthorne <[email protected]> > >> 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 > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
