Start a new topic

Evaluating the MT 'Team' feature

Yesterday's improvement of the MT 'Team' feature has lead me to some tests.


Here's a segment that has been translated without the Team feature:


image


Same segment, MT translated with use of the Team feature. Now the glossary entry has been injected into the MT suggestions:


image


Note that DeepL's translation shows {1} instead of the glossary entry. However, when transferring the suggestion to the Target segment editor, the glossary entry is injected correctly.


Also note, that the full stop is duplicated in some suggestions and in the Target segment editor. Perhaps this can be fixed (at least in the Target segment editor)?


Another segment without the Team feature:


image


And with the Team feature:


image


One question: has this useful feature been present before, or is it new?


image



Another question: why is it that the rest of the suggestions (the words other than the glossary entry), are totally different to, with and without the Team feature?


Do the MT systems receive different source segments, depending on whether Teaming is on or off?

When the Automatic transfer to target segments is checked, e.g. for DeepL, the suggestions are not transferred automatically.

The Team feature in the context menu seems to be independent from the setting of the Team feature in the Prefs. Is that correct?


And can the Team setting be set for different MT systems, differently? Is that really a feature?

Perhaps this is a glitch in the Team high-priority fragments only. I noticed that this one was checked. Now that I've unchecked it too, and restarted,  Automatic transfer to target segments is checked no longer.


BTW: Team high-priority fragments only should be a sub-option of the Team feature (only be available when Team is selected). I guess that this is difficult to implement on all supported platforms?

>When the Automatic transfer to target segments is checked, e.g. for DeepL, the suggestions are not transferred automatically.


Works for Google Translate, not for DeepL.

Team auto-assembling with machine translation is meant for substitution of some terms provided by MT with your glossary/memory  terms. If you use a few glossaries or memories for fragments, it is recommended to set the highest priority for the ones taking part in the "team" feature. Then, just activate "Team high priority fragments" only option in Edit > Preferences > MT tab. It will prevent from substitution  of low quality terms/fragments from your resources avoiding the substitution "noise". In my option, the feature works at best when there are no more than 2 or 3 substitutions in the segment. The source segments sent to the MT service are stripped off the source terms to be substituted with their terms from your resources. Also, neural network MT algorithms (e.g such as DeepL) can  provide such a translation that the substitution for a term may sometimes fail. The glitch with doubling of neighboring punctuation characters during the substitution will be fixed soon in the next build. Thanks!

You are welcome :)


And thanks for fixing that glitch.


>When the Automatic transfer to target segments is checked, e.g. for DeepL, the suggestions are not transferred automatically.


You cannot replicate this? (Note that I have 4 MT engines running.)


>The source segments sent to the MT service are stripped off the source terms to be substituted with their terms from your resources.


That's how I thought that it would be implemented. However, although this is a very good approach for masking non-translatables, it isn't a good approach to handle hi-prio glossary entries.


The reason is (as you can see in the screenshots: compare the suggested MT translations with and without teaming) that leaving out a source term when sending a segment to the MT system, will reduce the quality of the suggestion dramatically. Besides that, your giving the MT system information about incorrect translations. From a translator's perspective, sending any feedback about quality to an MT system is a no-no.


A better approach (tough way more difficult to implement) would be:


  • Send the unchanged source segment.
  • Calculate the position of 1 or 2 hi-prio glossary entries in the sent source segment.
  • Here we have the big problem: how on earth to determine the corresponding (wrong) target term. I'm afraid that this is impossible.
Let me think again. Another attempt:
  • Send the unaltered source segment to the MT system.
  • Remember the user's overriding the wrong target term (fragment). Save it either during the session or in a list.
  • Reuse it automatically in any further segments in the project (session).
That would be the most elegant and automatic way.

A little less elegant, semi-automatic solution:
  • The user will have to add wrong target terms to his glossary (or TM) and tag them as wrong. E.g. 'zeehond' instead of 'afdichting, pakking' for 'Dichtung':  Dichtung\tafdichting;pakking;*zeehond
  • CafeTran Espresso 2018 reads the whole hi-prio glossary entry when analysing a source segment. Whenever an alternative target translation, tagged as incorrect, is found, this incorrect target translation(s) will be replaced in the returned MT suggestion, with the first target translation after the TAB character. (For best warning, incorrect target translations could be coloured red in the glossary pane.)



> Works for Google Translate, not for DeepL.


Please deactivate it in GT pane and activate in DeepL pane.



Login to post a comment