Menu
▾
▴
#1369 Add support for custom MT for Microsoft Translator Hub
If you train your own MT system in Microsoft Translator Hub (see
https://hub.microsofttranslator.com/Help/Download/Microsoft%20Translator%20Hub%20API%20Guide.pdf), you can't currently use it inside OmegaT, because "MT Hub requires that you list the category parameter for your specific translation model for you to see the results from your deployed training system." It would be nice to have this integration available in OmegaT, so that users can choose between the generic MS machine translation engine and a custom one.
Let me react about one remark which came in the discussion list:
Yes, but since your plugin already asks for one parameter (the key), it is probably possible to support more parameters, right?
But this conducts me to a reflexion about your plugin architecture.
Actually, MT engines are always singletons.
Now imagine that some people want to see two results from MS Translator : one from the global, and one from the personal engine. You can create two subclasses, as you did for MyMemory.
But then, imagine that some people created several trained engines (for example per thematics: one about agriculture, one about transport, etc.) and want to decide which one to use depending on the project.
As you can understand, when an engine is susceptible to have multiple instances, which is the case when it is based on training (you may have the same problem for Moses, for example), support in OmegaT cannot be based on singletons anymore.
In my projects related to OmegaT, I added the possibility to create translation memory plugins, which are even more susceptible to have multiple instances than MT engines. The idea is that you add one or more engine descriptors in your project, each descriptor is a properties file which contain all connection parameters, including the collection or category, as you prefer to call it. Then I did the same for glossaries. So, if you want to extend your plugin API to support multi-instance MT engines, I can help because I already have the experience of similar improvement.
To summarize, we have here 3 possibilities:
1. add a parameter to existing engine, meaning that the user will have to choose between personal and global engine, without any possibility to use both;
2. duplicate the class, giving the possibility to use at same time one global and one personal engine, but not more;
3. one class with parameters, and descriptors in the project so that you decide at project scope which categories (in plural) you want to be connected to.
I understand that the 3rd one is the most complex one and you did not have any other plugin working like that until now.
I stop here to avoid being too long. Tell me if you are interested and I can give you more details, and even send you some links to make tests.
Regards
Thomas
So, if I understand correctly, one way to achieve this is to add a parameter at OmegaT project level, with the information needed to connect to a specific MT engine and then pass this parameter once you call the MT. From a user point of view, the mechanism should allow users to configure this project parameter, but fall back on the general MT (in the general Options), if none is set.
This option (number 3) is for the case of an engine which can have lot of instances (one per thematics, for example) so that some projects may want to connect to only some instances (this is more complex than a project "parameter", simply because some projects may want to connect to two or three categories, while for other projects it is better to connect to global project)
Several instances mean that the "Machine translation" pane will display 2 or 3 entries, with the name of the category, while actually it only contains the name of the engine.
I perfectly understand that this is difficult to imagine if you did not see it before. That's the reason why I suggest the following: I already did it for TaaS glossary (which has a notion of category), so if you can test it, then you can tell me if it makes sense to do the same for Moses and Microsoft MT engines, or if you prefer a global (for all projects) configuration as actually.