Re: [e4-dev] Eclipse Internationalization with the new message extension

[Daniel Rolka <Daniel.Rolka@xxxxxxxxxx>]

Hi,

For me it is also +1

Daniel

IBM SWG Lab, Cracow, Poland

IBM Polska Sp. z o.o. oddział w Krakowie
ul. Armii Krajowej 18
30 -150 Kraków
tel. +48 12 628 9993

NIP: 526-030-07-24
Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS
KRS 0000012941, Kapitał zakładowy: 34.650.000 PLN

From:	Wim Jongman <wim.jongman@xxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date:	09/04/2013 11:26 AM
Subject:	Re: [e4-dev] Eclipse Internationalization with the new message extension and the Eclipse translation pattern
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

+1


On Wed, Sep 4, 2013 at 10:58 AM, Lars Vogel <lars.vogel@xxxxxxxxx>
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 <John_Arthorne@xxxxxxxxxx>
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 <tom.schindl@xxxxxxxxxxxxxxx>
To:        e4-dev@xxxxxxxxxxx,
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:        e4-dev-bounces@xxxxxxxxxxx

---

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 <tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>>
> 
>     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
>     > e4-dev@xxxxxxxxxxx
<mailto:e4-dev@xxxxxxxxxxx>
>     > https://dev.eclipse.org/mailman/listinfo/e4-dev
>     >
> 
>     _______________________________________________
>     e4-dev mailing list
>     e4-dev@xxxxxxxxxxx
<mailto:e4-dev@xxxxxxxxxxx>
>     https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> 
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev



_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev



_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev