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]>> > > 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]> > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] <mailto:[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
