They don't support switching at runtime but they need to support multiple locales in one osgi instance
Tom Von meinem iPhone gesendet Am 04.09.2013 um 11:37 schrieb Dirk Fauth <[email protected]>: > 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]>> >> > >> > 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 >> >> >> >> _______________________________________________ >> 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
