Am 16.12.10 20:59, schrieb Oleg Besedin: > > Hi Tom, > Nice write-up. It might make sense to create a set of Wiki pages based > on your post so that design can be updated as it evolves. > > The most important part is the design goal. The 3.x approach is highly > optimized for the "simple" case, but does not support more complicated > scenarios. To me, it feels like the proposed new design would support > well the advanced use cases, but at the expense of > performance/scalability/usability of the simple case. (Simple case > being: having one language that does not change). >
Scalability/Performance only depends on the translation provider. >From a usability point of view I don't see any difference for the simple use case: The developer stores translations in the very same .properties-File like he does in plugin.xml and references them identical in the e4xmi-File. Translation usage in business code is IMHO the same than it was with NLS: 3.x: ---- String myMessage = MyMessage.myMessage 4.x: ---- MyMessage messages = ... // DI or through a factory String myMessage = messages.myMessage > So, I'd add the following two goals: > - it should be possible to describe the basic part of "the new NLS" to a > plug-in developer in under two paragraphs; Ok. > - it should scale well enough to not to be a memory or CPU hog for large > size applications This only depends on the available ITranslationProvider. We could write a translation provider which works identical to cached translation stuff in extension registry. So it has no influence to the design of the API but is a pure implementation detail. 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] https://dev.eclipse.org/mailman/listinfo/e4-dev
