Re: [e4-dev] [Proposal] Locale switching

[Dirk Fauth <dirk.fauth@xxxxxxxxx>]

Hi,

I worked on the LocaleChangeService with feedback from Tom. Several facts:

1. The LocaleChangeService is not a OSGi service, but will be created via context function.

2. It has additional methods for setting the Locale via String, which is in respect to the TranslationService.LOCALE that is represented as String also.

3. There is an event fired on Locale change.

4. The model update is triggered directly (so the event might not be necessary, but who knows all use cases a user might have).

5. The Locale needs to be set to the OSGi context and not the application context, as the model seems to only checking the OSGi context.

I've implemented some functionality that iterates over the model below the MApplication and filters out all MUILabel elements. It then exectues EMF notifications to update the UI. So the update can be triggered via model and it is not necessary to listen for events in the renderers, which should simplify things a lot.

This works fine so far, but at this point the implementation gets ... well ... kind of ugly. I need to determine the concrete model implementation as I need to specify the EMF notification feature ID which is tight connected to the model. For example, to execute the EMF notification for the label of a MPart you need to execute eNotify() on PartImpl like this

PartImpl impl = (PartImpl) element;
impl.eNotify(new ENotificationImpl(impl, Notification.SET, BasicPackageImpl.PART__LABEL, oldLabel, label));

I wouldn't need to cast directly to PartImpl. Usually UIElementImpl should be good enough to call eNotify(), but I need to know about the BasicPackageImpl.PART__LABEL feature id.

This would leave me to implement a set of instanceof checks for every model element, so I know what feature needs to be updated in detail. Isn't there a more generic way to execute a notification that the label needs to be updated?

Another idea would be to extend the MUILabel to contain a updateLocalization() method or something like that, that hides the implementation about what needs to be done for updateing such information. This would also allow the implementations to override, as for example parts also come with descriptions that are able to be localized and that are not specified in MUILabel. Would that make sense?

What do you think? Any help or idea is appreciated. I implemented the locale change already for MWindow and MPart (which is easy when you only need to implement at one place), and it works very nice. Would love to finish this in the right way to get the locale change feature completely done for Luna.

Greez,

Dirk

On Thu, Nov 21, 2013 at 12:51 AM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:

Hi,

Yeah i know about LocaleProvider but have never used it myself. I also
think its going to be hard to implement what our current translation
system can do (e.g. we can switch the locale only for a certain area of
the application, ...).

If I get LocaleProvider right i would have to inspect the call-stack to
find out where from I am called, to me this service looks like it is
e.g. designed for systems like RAP where the have a "thread-local" to
store the locale for each instance.

What we can do although is to inform the LocaleProvider (in case there
is one) about the language change.

On the injection story: Clients can already today let themselves inject
the locale because we are pushing it into the IEclipseContext, the
problem for the renderes is that they problem won't get an injection
when the user does not flip the whole application but e.g. the Java
perspective.

The renderers are bound to the application context and so won't get
notified.

Tom

On 20.11.13 17:21, John Arthorne wrote:
> You probably already know about it, but I wanted to mention the existing
> LocaleProvider API in Equinox. It is intended to isolated clients for
> the process of locale lookup, and is used for example to support
> multiple simultaneous locales in the extension registry. Ideally the
> multi-language story for the application model should be consistent with
> this, so an application that wants to provide multi-locale doesn't need
> to register multiple mechanisms. Something like LocaleProvider, combined
> with an event on the event bus that notifies on locale changes, feels
> like the basic pieces we need. On locale change clients could use
> LocaleProvider to obtain the new value. For injection clients we could
> even directly inject Locale object directly and take care of the
> events/dynamism within the framework.
>
> John
>
>
>
> From:        Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
> To:        E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
> Date:        11/19/2013 06:31 PM
> Subject:        [e4-dev] [Proposal] Locale switching
> Sent by:        e4-dev-bounces@xxxxxxxxxxx

> ------------------------------------------------------------------------

>
>
>
> Hi,
>
> Now that the new message stuff is in the runtime repo I've been having
> offline discussions with Dirk Fauth on how to get dynamic language
> switching for the complete e4 UI.
>
> I guess most of you know that the the low-level of our model is prepared
> to make such a language switch possible at ANY level of the application
> because the locale is resolved against the nearest context.
>
> So here's our proposal to allow applications to switch the language:
>
> a) Language switch is announced through the event-broker
> b) Renderers register themselves as listeners and update the localized
>   data
> c) Language switching is provided to clients through
>   LocaleSwitchService. A first draft looks like this:
>
>   interface LocaleSwitchService {
>      public void switchApplicationLanguage(Locale locale);
>      public void switchContextLanguage(IEclipseContext c,Locale locale);
>   }
>
> I'm a bit indifferent on switchContextLanguage because I don't feel
> comfortable exposing the IEclipseContext in any API and I'm uncertain
> switching the language at a certain context is the 99% case. I currently
> lean towards switchApplicationLanguage.
>
> This E-Mail is just to get out the message that there's something coming
> maybe in Luna, I won't do the work myself but help Dirk to accomplish
> the task.
>
> Tom
> _______________________________________________
> 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