Maybe Patrick Porter can help you with that one?  He did this in his plugins already I believe - MT Enhanced Plugin for Trados Studio

Thanks Paul.

Patrick, if you could give us a pointer that would be great.

I suspect it's something to do with the translation status and origin, e.g. if status is "translated" or the origin is "automated translation" then don't send it to MT, or something along those lines?

Cheers

John

Hi John,

I'm sure that Patrick Porter is writing a response to this as we speak, but you are right on the mark; the current translation state from the translation Origin maintains this information (along with the previous orgin states) and you can use those properties to make a decision whether or not to query your provider.

I would suggest that you also manage an additional option with your settings that allows the user to ignore segments that are already translated so that the can also override this if required.

In some cases I also manage a cache of the translations returned from the provider so that I can reuse those translations from cache as opposed to re-querying the provider for the same source segment + content structure.

P.

Hi John,

You need to get a handle on the TranslationOrigin; Include this code in one of the SearchTranslationUnit methods...

 MessageBox.Show(
                "ConfirmationLevel:\t\t" + translationUnit.DocumentSegmentPair.Properties.ConfirmationLevel.ToString()
               + "\r\nIsLocked:\t\t\t" + translationUnit.DocumentSegmentPair.Properties.IsLocked.ToString()
               + "\r\nOriginType:\t\t" + translationUnit.DocumentSegmentPair.Properties.TranslationOrigin.OriginType.ToString()
               + "\r\nOriginSystem:\t\t" + (translationUnit.DocumentSegmentPair.Properties.TranslationOrigin.OriginSystem != null ? translationUnit.DocumentSegmentPair.Properties.TranslationOrigin.OriginSystem : string.Empty)
               + "\r\nIsRepeated:\t\t" + translationUnit.DocumentSegmentPair.Properties.TranslationOrigin.IsRepeated.ToString()
               + "\r\nIsStructureContextMatch:\t" + translationUnit.DocumentSegmentPair.Properties.TranslationOrigin.IsStructureContextMatch.ToString()
               + "\r\nTextContextMatchLevel:\t" + translationUnit.DocumentSegmentPair.Properties.TranslationOrigin.TextContextMatchLevel.ToString()
               + "\r\nMatchPercent:\t\t" + translationUnit.DocumentSegmentPair.Properties.TranslationOrigin.MatchPercent
               + "\r\nConfirmationLevel:\t\t" + translationUnit.DocumentSegmentPair.Properties.ConfirmationLevel.ToString()
               );

Example:

ciao,

P.

Hi John,

Just reading this now...

from memory... I also had some problems with this becuase the ISegment isn't exposed, correct?

I will check/test later on but you could try to initialize the translation unit with an additional SearchResult class and take some of the properties from the ScoringResults (I think that is what it is called)... there should be a few properties in there that resemble in part what is maintained with the TransaltionOrigin...

I will try to follow up later on if i get a chance to look at some code and see if what I am saying here makes sense /or works

P.

Thanks so much Patrick, I guess for 2011 we'll just use the ConfirmationLevel as a more coarse solution than we can do in 2014.

This begs another question though - how do we maintain multiple versions of the same plugin but for different versions of Studio (this is what I think we'll need in this case, as we're making use of parameters in 2014 that don't exist in 2011). Perhaps Paul can answer?

(P.S. how do I tag someone in a post? like Paul in this case?)

Easy way (I think) is to search for a user in the search box at the top, and when you see the person show up click on them and you get the url to their name.  Paul Filkin or John Tinsley for example.

On your actual question I think you have two options.

1. This is the preferred option in my opinion.  You create an installer that contains appropriate code for each version.  If the user has multiple versions installed then you ask which one or just do them all.  Otherwise you see which version is there and install the appropriate stuff.
2. Create a new app altogether so you have different versions on the OpenExchange

I think the second is less preferable because it means the users could get confused if they don't notice this, and your downloads get split up so they are not cumulative... cumulative is better so you climb the download charts more eficiently.  This is useful because some people browse the apps by download to see what's most popular.

Easy way (I think) is to search for a user in the search box at the top, and when you see the person show up click on them and you get the url to their name.  Paul Filkin or John Tinsley for example.

On your actual question I think you have two options.

1. This is the preferred option in my opinion.  You create an installer that contains appropriate code for each version.  If the user has multiple versions installed then you ask which one or just do them all.  Otherwise you see which version is there and install the appropriate stuff.
2. Create a new app altogether so you have different versions on the OpenExchange

I think the second is less preferable because it means the users could get confused if they don't notice this, and your downloads get split up so they are not cumulative... cumulative is better so you climb the download charts more eficiently.  This is useful because some people browse the apps by download to see what's most popular.

Thanks Paul. We'll have a look at how to implement the first option you've proposed.

John