Since DGT users do not have the possibility to use external MT engines, for confidentiality reasons, the following features are only here for the public version.

Preferred MT engine

When OmegaT inserts the result of machine translation (via the menu "replace with machine translation", or CTRL+M) there is no way to decide which engine you want to use : the inserted text depends on which engine did answer faster than others. For the automatic insertion (see previous page) it was also initially the same.

Maybe you may want to see the results from more than one engine, but have a preference about which one to insert. There is now a ne option for that:

The option will be only visible if you have more than one existing engine : if you remove mt_plugins.jar, only the "local" engine remains so the option disappears. The rule is that on any insertion (including manual one via "Replace by machine translation"), OmegaT will insert the result of the selected engine, if available. If not, and if other engines did give an answer, the result is, as usual, not deterministic.

Caching results

OmegaT 3.5 introduced the possibility to cache in memory the result of machine translation engines, in order to avoid to call several times for the same phrase. The idea, by itself, is good. But the problem is that OmegaT developers consider that any MT engine, by default, should take profit from a cache: this is not true for our local engine - caching in memory what is already in memory is totally useless. And also we have some pseudo-machine translation engines, which share the same interface but should not use a cache.

For that reason, our cache is a little bit different: external engines hich want to use a cache must extend the class CachedTranslate, which already extends BaseTranslate to add cache to it. Those which do not need a cache (not only the tmx folder: the local version of Apertium could do it as well) should simply extend BaseTranslate or simply the interface IMachineTranslation (in which case they do not appear in the top menu as you cannot "enable/disable" them). 

Distinction between error and good results

In standard OmegaT, when an external engine encounters an error, it simply puts it in the result returned to the GUI. Even if the interface accepts to throw an exception, most engines never do it. This can be a problem for users of automatic insertion, since your preferred engine is suceptible to insert an error in your segments.

All external engines have been modified to really throw exceptions, instead of encapsulating them into strings. To make it more visible, now the "machine translation" pane uses two colors: green for a real result, and red for an exception. And if we speak about automatic insertion (either by option or using CTRL+M), only green results will be inserted: if your engine returned an exception, even if it is your favorite one, the algorithm will look for the next engine. Note the presence of an indication about how long the request took time: this is a good indication about cache efficiency. In any case this is an option for which we added a specific entry in the MT menu. Last but not least, if you click with right button on the green translation, a menu enables to insert or to replace in the editor with the current translation. This is useful in case the corresponding engine is not your favorite one.

Permanent exception

When you activate an engine with bad parameters - wrong key, or simply not supported language pair - it is pretty sure that the same error will occur for every segment until you make the correction. So it is totally useless to call the engine again, the result would be the same. Such an exception wil be kept in memory and prevent any new call of the engine - only results in cache will be retreived.

Not all exceptions are concerned: for example an error due to a wrong character inside the input string is not a permanent exception, since it is specific to a segment. This is the responsability of the engine's author to decide which exceptions should be considered as permanent or not.

Actually when you have such an exception, the only way to get the engine working again is to stop and start the application. In the future we may make the distinction between project specific errors (a problem with language pair is solved when you change project properties), configuration errors (for example a wrong key is solved if you give a new one), etc.