They sure have. You can find the necessary information here:
For sure it would be a really cool stuff.
There are two points:
- we need to create a plugin (.net knowledge required) as a matter of fact there are existing plugins similar to this (mymemory, teminotix, …)
- you need a REST API layer on top of openNMT to expose the engine to the plugin.
If you want an example of similar RESTAPI, you can have a look at MMT.
https://github.com/ModernMT/MMT/wiki/API-Documentation
Compatible one would be even better …
Note that we do have a working ZeroMQ server implementation now checked in
https://github.com/OpenNMT/OpenNMT/tree/master/tools#translation-server
It is a bit more low-level than REST. But it basically implements this REST call (https://github.com/ModernMT/MMT/wiki/API-Documentation#translate-text)
You could easily call this using the ZeroMQ .net library.
https://github.com/zeromq/netmq
I don’t have access to Trados/.NET but happy to answer any questions.
1 Like
OKAY,
it becomes a little off topic now but if we really want something that works in a real world here is what is required:
SDL plugin: it acts as a translation memory provider, which means you can pick an “engine” which encompasses a language pair. egs: in the plugin settings you can chooses FR=>EN or EN=>ZH
Then the plugin will call a REST layer including the langue pair.
That Layer will call you zeromq 1 (for EN=>FR) or zeromq 2 (for EN=>ZH)
Bottom line:
For the SDL Plugin, we can provide some input.
For the REST Layer: 2 choices: either you want to remain in the lua environment, someone will have to do that.
either this can be done in another language like nodejs and we may help.
any insight ?
I don’t think it is necessary for the server to be in Lua. Feel free to use whatever language is easiest.
Explain to me why the plugin cannot just call the current server1 or 2 directly, is Trados limited to HTTP calls? I’m happy to add an http/rest option to the opennmt server if that is helpful.
Everything is possible as you know BUT don’t forget that the SDL plugin is 100% end-user oriented.
The end-user wants to know one thing: a URL+port, a language pair.
If we put too much settings in the plugin, it won’t be usable by anyone (end-user or IT guys @end-user)
A multi-lingual REST layer is needed in my view.
We have started one, along with the SDL plugin, which communicate with the ModernMT back end.
I think there an added-value to be compatible with some other existing systems.
Only issue I see, it may really overlap with some stuff taht the Systran folks do on their end.
Great! I’m pretty terrible at end-user stuff. Let me know if anything in the backend needs to change 
after a second thought, here is what makes the more sense:
We create a github repo on our end with 2 items:
- the sdl plugin
- the multilingual REST Layer, which can be configured to connect either an OpenNMT REST API or the existing ModernMT REST API
this makes everything flexible. So yes if you have a resource to add the rest option to opennmt that would be great.
Do we have a plugin for SDL now? Is this something in the works?
@vince62s You mentioned that you have started a multilingual REST layer which communicates with ModernMT back end. Is this available? Will you make it open-source?
Thanks in advance!
I have created a plugin for SDL Trados Studio that works with the rest_translation_server. Pretty simple at first as it only accepts the server address and the port, but it works. Is there still interest for this or anything fancy is coming from OpenNMT/Systran ?
Hi @panosk - we actually do have a plugin but a bit too fancy to share because it comes with a lot of extra layers. It would be great to share yours with the community. I created a repository OpenNMT/plugins and will be glad to review a PR there.
1 Like
I have also put a plugin in the SDL appstore (: http://appstore.sdl.com/app/mydutchpal-neural-mt-plugin-for-sdl-trados/633/.). It’s geared to send strings through an intermediate server for pre-processing before arriving at the rest_translation_server. However, if there’s interest we could adapt it to be available for general use.
I guess we’re all in the same situation where it requires adaptation with some extra layers, quite difficult to generalize for each scenario. That was the reason why I gave up after suggesting it in this thread.
1 Like
As I said the plugin is very simple and I created it within a day for personal use. With that said, a translator only needs to actually receive translations for their project/language pair, so in that sense it is (almost) ready for personal, real-life use. Now, for fancier things, like choosing language pairs/models, etc, or for large companies with many translators/language pairs, I think there’s not much that can be done right now in the front-end because the server doesn’t expose this information.
Anyway, I don’t use often Visual Studio/.NET/C#, so this simple plugin could serve as a starting point so others can contribute and do nice things as OpenNMT and its servers evolve.
Btw, the plugin is developed based on Trados 2014 APIs.
@panosk - thanks for submitting the code. I would like to set the license for the full repository to MIT like the rest of the OpenNMT project - is it ok for you? If you wish, you might want to add a specific license MIT disclaimer with your name in the repository like here: https://opensource.org/licenses/MIT
1 Like
Hi Terence, do you think you can share with us your SDL plugin? I believe this will be a great addition to OpenNMT. Thanks in advance!
Hi Mohamed,
That particular SDL plugin is linked to a commercial service and I can’t share it on the forum. However, I’ll have a word with the developer to see if we can create a “language-neutral” version which we can share.
Terence
1 Like
Thank you so much, Terence! This would be amazing. Thanks again for your support!