Yeah, I realized that was probably the case after I sent the message. In that case, you're looking for something similar to what we've done in UML2 for profiles/stereotypes (which are essentially dynamic EMF models). There, we've implemented a mechanism that does dynamic look-up of strings in .properties files that are co-located with the model, possibily in a plug-in/fragment. If you're interested, check out the source for org.eclipse.uml2.common.util.UML2Util#getString(...).
Cheers, Kenn On Mon, Apr 12, 2010 at 2:19 PM, Tom Schindl <[email protected]>wrote: > Hi Kenn, > > I'm not sure item providers can really help us here because we talk > about translating the value in an attribute and I think we can do that > as good our own. > > What we need to do is something like this: > > TranslationService service = ...; > String l = label.getLabel(); > > if( l.getLabel() != null && l.getLabel().charAt(0) == '%' ) { > l.setLabel(service.translate(l.getLabel())); > } > > Tom > > Am 12.04.10 19:42, schrieb Kenn Hussey: > > Tom, > > > > Why can't the item provider mechanism from EMF (which provides full i18n > > support) not be used here? > > > > Kenn > > > > On Mon, Apr 12, 2010 at 12:11 PM, Tom Schindl > > <[email protected] <mailto:[email protected]>> > wrote: > > > > Hi, > > > > Am 12.04.10 17:50, schrieb Paul Webster: > > > First let me say, the ability to NLS the workbench model is > required > > > as well as important :-) AFAIK we need to implement this before we > > > ship. > > > > > > That being said, what are the options? Our workbench model > consumes > > > as well as replaces some aspects that are provided in 3.x by 1) > > > programmatic contributions, that can use the eclipse NLS support > and > > > 2) extensions that usually are translated in the plugin.properties. > > > > > > So we now have an EMF model in the center of our workbench. What > is > > > the EMF support for i18n? Does it have a similar capability where > an > > > attribute value is %whatever and it can be directed at load time to > > > .properties files? > > > > No it hasn't anything we can use in our case. > > > > My take on it is that NLS should not be implemented as Decorators > (=the > > translation is done on the fly by the Renderer) but the renderer > should > > render the value really stored in the UILabel#label. > > > > I think it can work like this: > > ------------------------------ > > after having loaded the model we but before we apply the deltas, we > > traverse the model and replace the label-attribute with the > translation > > we retrieve through a TranslationService. > > > > I think we should remember the original value in a transient > attribute > > so that we can reset the value to its original translation though. > > > > Does this make sense? > > > > Tom > > > > -- > > B e s t S o l u t i o n . a t EDV Systemhaus > GmbH > > > ------------------------------------------------------------------------ > > tom schindl > geschaeftsfuehrer/CEO > > > ------------------------------------------------------------------------ > > eduard-bodem-gasse 5/1 A-6020 innsbruck phone ++43 512 > 935834 > > _______________________________________________ > > 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 > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl geschaeftsfuehrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5/1 A-6020 innsbruck phone ++43 512 935834 > _______________________________________________ > 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
