You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 19, 2023. It is now read-only.
I used your OpenNMT Trados plugin as a guide for building my own plugin, since the Trados documentation is so lousy. I'm exceptionally grateful for your example and the work you put into it.
Just a few minutes, ago, I identified a possible race condition in my implementation of LanguageDirection, and I wanted to warn you about it.
It appears that Trados (at least Trados 2017) does prospective translation; it translates the segment you select plus a couple following segments. And it appears to reuse the LanguageDirection object for the translations in subsequent segments that it stores, and it seems to do this translation in parallel threads. What this means is that the element visitor is being reused across threads, and if translations come back out of temporal order, the contents of the visitor will have changed by the time the translation is done. In my case, my translation engine is asynchronous, and it appears that in your code, it isn't; but I don't think that makes a difference if your server can handle multiple parallel requests. So the potential bug is retrieving the value of the PlainText property from the visitor after the translation is done, rather than grabbing it before the translation and using that stored value. The symptom I've been observing is that in the Trados editor view, sometimes the source element of the proposed translation pair in the top section is wrong, even though the target is always correct.
Actually, the true bug is reusing the visitor at all. But cacheing the value that's sent to the translation engine and not consulting the visitor again seems to work.
The text was updated successfully, but these errors were encountered:
Hi @slbayer ,
Thanks for your input, I'll be able to look into it some time next week. In the meantime, if you have a fix for it, please go ahead and send a PR.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi folks -
I used your OpenNMT Trados plugin as a guide for building my own plugin, since the Trados documentation is so lousy. I'm exceptionally grateful for your example and the work you put into it.
Just a few minutes, ago, I identified a possible race condition in my implementation of LanguageDirection, and I wanted to warn you about it.
It appears that Trados (at least Trados 2017) does prospective translation; it translates the segment you select plus a couple following segments. And it appears to reuse the LanguageDirection object for the translations in subsequent segments that it stores, and it seems to do this translation in parallel threads. What this means is that the element visitor is being reused across threads, and if translations come back out of temporal order, the contents of the visitor will have changed by the time the translation is done. In my case, my translation engine is asynchronous, and it appears that in your code, it isn't; but I don't think that makes a difference if your server can handle multiple parallel requests. So the potential bug is retrieving the value of the PlainText property from the visitor after the translation is done, rather than grabbing it before the translation and using that stored value. The symptom I've been observing is that in the Trados editor view, sometimes the source element of the proposed translation pair in the top section is wrong, even though the target is always correct.
Actually, the true bug is reusing the visitor at all. But cacheing the value that's sent to the translation engine and not consulting the visitor again seems to work.
The text was updated successfully, but these errors were encountered: