If you look how the localize methods in the model they look up the locale you'll notice that the look at the nearest context, IIRC
Tom Von meinem iPhone gesendet > Am 02.12.2013 um 21:03 schrieb Dirk Fauth <[email protected]>: > > For the context stuff: > > In E4Application.createDefaultHeadlessContext() the Locale value is set to > the service context. > > IEclipseContext serviceContext = E4Workbench.getServiceContext(); > ... > String locale = Locale.getDefault().toString(); > serviceContext.set(TranslationService.LOCALE, locale); > TranslationService bundleTranslationProvider = > TranslationProviderFactory.bundleTranslationService(serviceContext); > serviceContext.set(TranslationService.class, bundleTranslationProvider); > > If I set the value for TranslationService.LOCALE to the application context, > the application model is not changing the localized values. If I set it to > the service context, it works. > > If I understand it correctly, than the TranslationService is lying in the > service context. Therefore it does not know about the application context. > And therefore the model only knows about the Locale in the service context. > Does that make sense? > > >> On Mon, Dec 2, 2013 at 6:14 PM, Dirk Fauth <[email protected]> wrote: >> My understanding of the model is yet not deep enough. I guess I need some >> more detailed information on how to do this. :-( >> >> Am 02.12.2013 16:58 schrieb "Tom Schindl" <[email protected]>: >> >>> On 02.12.13 16:49, Dirk Fauth wrote: >>> > 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. >>> > >>> >>> We can solve all of this with: >>> a) make the localize* attributes volatile, transient, derived features >>> b) introduce a mixin interface with your proposed method >>> c) make MUILabel implement the mixin >>> => send out events derived features >>> d) make the renderers listen to new volatile features >>> >>> The advantage is that people deriving from our model can implement our >>> mixin and do the appropriate thing. >>> >>> Tom >>> _______________________________________________ >>> 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
