Re: [e4-dev] Set up of my translation scene

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Hi Jürgen,

Thanks for your input. Our approaches seem really quite identical. I
think the only real difference is that you are search for the one who
provides the translation as part of the Framework-Code whereas I would
put such a chain of responsibility in your ITranslationProvider.

The main reason for me to not make such a thing not part of the
framework is that I have to compete with the 3.x codebase and if I'd put
such a thing into the core framework I would force people to buy my idea
which is not a good thing :-)

If you are interested CVS holds a working version of Contact-Demo which
uses the translation story like I envision it when it comes to custom
code. Once we (currently only Oleg and me) have agreed that my
implementation satisfies everybody (see bug 331260). I can start working
on supporting this for our model.

Tom

Am 29.12.10 19:22, schrieb Jürgen Kropf:
> Hi Tom,
> I write this in response to your recent proposal to translation.
> 
> Albeit not (yet) using e4, we employ an approach very similar to yours
> which might be interesting to you.
> (Indeed, even the names of our interfaces are identical to yours :))
> 
> We have an ITranslationService which obtains ITranslationProviders
> declared by extensions.
> The actual translation is performed by an ITranslator instance which is
> obtained by the ITranslationProvider. The principal method called on
> ITranslator is getString(String key), which returns the translation for
> the given key. Some other methods, e.g. getString(String key, Object ...
> arg) or getString(String key, Locale locale) are provided too.
> 
> The ITranslationProviders follow a chain of responsibility pattern and
> one of them is selected by the ITranslationService by using the first
> one returning a non-null ITranslator for a given locale and some context
> information, which is typically a Class or Package. The locale is
> optional and substituted by the system default locale if missing.
> 
> Additionally, an integer priority value is used to obtain some ordering
> of the ITranslationProviders.
> 
> We pre-define a ResourceBundleTranslator which uses the standard
> translation using .properties files and, as the last resort, a
> KeyReturningTranslator, which has lowest priority and always returns a
> ITranslator which just returns the given key. This provider is reached
> on falling through the responsibility chain without finding a real
> translator. (Alternatively, one might employ an
> 'ExceptionThrowingTranslator' to handle this case.)
> 
> In our applications, we further use a custom ITranslationProvider which
> is based on database lookup, and sometimes an ITranslationProvider which
> is based on com.google.api.translate.Translate, i.e. uses Google for the
> translation. Of course, the latter one is in no way perfect, but quite
> handsome for easily providing translations in exotic languages.
> 
> The priority sequence for our ITranslationProviders is (from high to low):
> Database,
> ResourceBundle ,
> Google,
> KeyReturning
> 
> 
> In the following code example I have included a simple mechanism we use
> to dynamically react on locale changes. These are managed by the
> ITranslationService and notifications are fired for interested listeners.
> 
> public class SomeClass implements ILocaleChangeListener {
> 
>    private ITranslator Messages; // we name it 'Messages', so we can use
> the 'Externalize Strings...' feature of Eclipse
>    private String translated;
> 
> 
>    public SomeClass() {
>        ITranslationService translationService = (ITranslationService)
> PlatformUI.getWorkbench().getService(ITranslationService.class);
>        translationService.addLocaleChangeListener(this);  // we want be
> informed on locale changes
>        Messages = translationService.getTranslator(SomeClass.class); //
> get a translator for the current default locale
> 
>        //...
> 
>        // looks identical to the .properties translation, but the
> translation might indeed be performed by database lookup etc
>        // this is completely transparent to the application
>        translated = Messages.getString("SomeClass.someKeyToTranslate");
> //$NON-NLS-1$
>        // ...
>    }
> 
> 
>    @Override
>    // called after the locale has been changed by the ITranslationService
>    public void localeChanged(ITranslationService service, Locale
> oldLocale, Locale newLocale) {
> 
>         // we just obtain an ITranslator appropriate for the new situation
>         //  newLocale could be omitted, because ITranslationService sets
> the system default locale
>         Messages = translationService.getTranslator(SomeClass.class,
> newLocale);
> 
>         // perform some translation for the new Locale
>         translated = Messages.getString("SomeClass.someKeyToTranslate");
> //$NON-NLS-1$
>         // ...
>    }
> }
> 
> Please excuse me for posting this stuff to the e4 development list
> without having a clear dependency to e4,
> but the similarities with your proposal seemed so, that this might be
> justified.
> 
> A happy new year
> 
> Juergen
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> 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