Hello Sam Bayer,

I will have a look on the topic you've described and I'll come back to you with an answer.

With kind regards,

Florentina Caputa

Hi Sam Bayer,

On our Github SdlCommunity public repository https://github.com/sdl/Sdl-Community, we have 2 providers: ETS and BeGlobal where the base score is setup from the code behind, as in your situation (see below print screen) 

In this case, even though you change the value from the "Project Settings" -> "Language Pairs" -> "Translation Memory and Automated Translation" grid, the score which was setup in the code will be taken into consideration.

Example: In the previews code print screen, you can see the score is set to 25, now I am changing the penalty to 10 in "Project Settings" -> "Language Pairs" -> "Translation Memory and Automated Translation" grid, and the search results will still work based on the score 25. (see below)

After the search results are displayed:

I suppose in your case, the penalty setup is missing , you can check in this API documentation http://producthelp.sdl.com/SDK/TranslationMemoryApi/4.0/html/9f65aced-c266-485d-bc6a-cb1973f8b0cc.htm. The below code is taken from documentation, and each side of the code is well explained. 

Please let me know if the above suggestion helped you.

With kind regards,

Florentina Caputa

I did miss that bit from the API, so thanks for pointing that out. This helps, but not completely. Why is the penalty specified in the UI not applied? In other words, in the example you show, your base score is 25, and the UI penalty is 10; why is the score of the translated element not 15?

Did you try to check the settings from the project, if the penalty setup in the UI is identified on one of the setting group, like:

private void UpdateProjectTMSettings(FileBasedProject project)
{
      var settings = project.GetSettings();
      var tmSettings = settings.GetSettingsGroup<TranslationMemorySettings>();
      tmSettings.MultipleTranslationsPenalty.Value = 10;
      tmSettings.MissingFormattingPenalty.Value = 0;
      tmSettings.DifferentFormattingPenalty.Value = 0; 
      tmSettings.AutoLocalizationPenalty.Value = 0;
      tmSettings.TextReplacementPenalty.Value = 0;
      tmSettings.TranslationMaximumResults.Value = 99;

project.UpdateSettings(settings);
}

In the above method, the translation memory penalties settings  are setup based on user's situation.

Clearly, there's something fundamental I'm missing here.

First, it seems like you're suggesting that Trados doesn't apply a penalty automatically to the output of the score that comes out of CreateSearchResult or its equivalent. Is this correct? If so, I'm curious about why; it seems to me that if you specify a penalty via the UI, the computation of the final score should be Trados' responsibility, not the responsibility of the plugin. What am I missing here?

Second, you seem to be suggesting that  if I can get a reference to the project object, I should be able to extract the settings that have been set in the UI. Is this correct?

Finally, I don't understand how to access the project object. I've traced through the translation provider API, and it doesn't seem to give you access to the project object anywhere: not in the Browse() or Edit() methods, and not in the segment translation methods. So if I need to access the project object to retrieve the settings to compute the score, how do I access the project object?

Thanks for your attention.

OK, I think I've answered part of my own question: the SearchSettings are passed in to the translation function, which I somehow missed. So I don't need to access the project object. So I can definitely apply the penalties by hand. But why do I have to? It seems like the ProviderPenalty ought to be applied automatically by the framework.

If you have an answer for that, it would be great. Otherwise, thanks for your help.

Just in case, if you will need in future to access the project and you don't know how, you can do it using the ProjectController:

Through the results of the above method, you can access information for the current project, all projects etc (see which are the properties,methods and events exposed through Project Controller in the following documentation: http://producthelp.sdl.com/SDK/StudioIntegrationApi/3.0/html/eecf814e-9f43-c81c-5579-91cac5fbe154.htm

Also, a good sample code on how you can use the ProjectController can be found here: http://producthelp.sdl.com/SDK/StudioIntegrationApi/3.0/html/8ee181e6-654a-4033-adf5-2f7ed6c9df83.htm

Wish you a good day,

Florentina.

Hello Sam Bayer

I'm a bit confused about your usecase, and I don't think this is going to be possible anyway.  The penalties apply to TM results that are calculated based on the match of the source segment against the TM.  With MT you don't have this at all, you only have an AT status and the ability to set the match value through the code (as you have done) so it can be seen if you hover over the AT or check within the sdlxliff.

As you are setting the value yourself through code I think this is always going to be the value and it will not be adapted with a penalty.  If you really want to have this ability I think you might have to build this in as a parameter the user can set within the UI for your provider.  But I'm not sure why this would be useful as the use of MT or not is based around the values you have set for TM matching and not MT.  Why would you set a specific value through the code and then adapt it with a penalty?

Thanks for those pointers. It turns out that I'd already used the project controller in another area of my code, but I'd forgotten it existed, sadly. I think one of the issues I had with it is that I was trying to use it during the selection of my translation provider to find out something about the project being shown in the Project Settings popup, but the project being shown in the Project Settings popup differs depending on which view you're in; in the Files and Editor views, it's the current project, but in the Projects view, it's the selected one. But in my current use case, I can definitely rely on its being the current project.

I thank you very much for your thoroughness and patience.

Hi Paul -

I can't say that there's a plausible use case - I'm the plugin developer, not the user, and the group I'm supporting is not, itself, intimately familiar with the complexities of Trados and its workflow expectations. But I can think of a couple reasons:

(a) the presence of a penalty setting in the UI that doesn't do anything is kind of mysterious and unfriendly to the user. The SupportsPenalties member in the TranslationProvider class doesn't cause the penalty cell to be disabled if it returns false. (In fact, I can't figure out what it controls, or what SupportsScoring controls. If you know, I'd love to know.) So just for user friendliness, I'd implement it (and, I'd argue, Trados itself should disable the penalty setting if SupportsPenalties returns false, and apply the ProviderPenalty automatically if it returns true).

(b) it's another way to control the priority of translations.

Beyond that, I got nothing :-).