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
