[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] Set up of my translation scene
|
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