Studio Developers Q&A - Recent Threads

RE: Verification plugin triggered when confirming a segment even if disabled

Patrick Andrew Hartnett — Sat, 18 Apr 2026 08:33:04 GMT

Hey Arturo Vazquez Rodriguez , This is a know bug and at the moment your only option is to implement your own mechanism to check if the project is disabled.

Here is an example of how you could accomplish this, let me know how it goes.

var extensionPoint = PluginManager.DefaultPluginRegistry.GetExtensionPoint<TranslationProviderFactoryAttribute>();
if (extensionPoint == null)
{
	return;
}
foreach (var extension in extensionPoint.Extensions)
{
	// 1. identify if the extension is a provider of interest to you
	// from here you can identify the type
	// extension.ExtensionType == etc..
	// extension.Plugin.Id == etc...
	
	// 2. identify if the provider is enabled; this should already solve yr problem
	if (extension.Enabled)
	{
	   // do something
	}
}

Verification plugin triggered when confirming a segment even if disabled

Arturo Vazquez Rodriguez — Fri, 17 Apr 2026 09:07:28 GMT

Hello,

I have developed a custom verification plugin for Trados Studio.

When I disable it in the project settings, it won't be triggered when pressing F8, which is expected and completely normal.

The problem is that confirming a segment triggers the verifications performed by that plugin even if the plugin is completely disabled (that is, unchecked in the Verification options node).

I am using Trados Studio 2024 SR1 18.1.3.6657

I cannot share the source code publicly or the plugin, but I can privately, please get in touch with me for that.

Thanks!

Kind regards,

Arturo

RE: Verification plugin triggered when confirming a segment even if disabled

Arturo Vazquez Rodriguez — Fri, 17 Apr 2026 11:27:00 GMT

Just adding here that disabling individual checks in my verification plugin works as intended: confirming a segment does not trigger the check if the individual check is disabled. Therefore, it seems that Trados is ignoring the status of the plugin enablement at the top level and only looking at the enablement status of individual options. Is there a solution for this I can put in place on my end?

RE: Error when setting value in import task settings

Patrick Andrew Hartnett — Tue, 14 Apr 2026 10:32:42 GMT

Hi Bram van der Steen , thank you for providing the source code. The team have reviewed this; here is the response:

This reproduces in Trados 2024 and 2022.

For comparison, I ran the task in Trados (Update from Bilingual Review) and compared the items added in the settings with what the user is trying to add programmatically. The item added by Trados has its Language property set to null, while the user is attempting to set it. If the code is changed so that the Language property is not set, the error no longer occurs.

Error when setting value in import task settings

Bram van der Steen — Fri, 31 Oct 2025 16:43:38 GMT

Good day,

In our plugin with Studio 2024, we are trying to run the automatic task “UpdateFromExternalReview” via the Studio API. However, when preparing the task settings, we receive an error. See the following code snippet:

ISettingsBundle settings = project.GetSettings();
Sdl.ProjectApi.Settings.ImportFromReviewTaskSettings importTaskSettings = settings.GetSettingsGroup<Sdl.ProjectApi.Settings.ImportFromReviewTaskSettings>();
importTaskSettings.ExternalReviewMappingItems.Value = reviewedItems;

When setting this value, we receive the following error:

No set method for property 'IsoAbbreviation' in type 'Sdl.Core.Globalization.LanguageBase'. ---> System.Runtime.Serialization.InvalidDataContractException: No set method for property 'IsoAbbreviation' in type 'Sdl.Core.Globalization.LanguageBase'.
at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.ThrowInvalidDataContractException(String message, Type type)
at WriteLanguageToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , ClassDataContract )
at System.Runtime.Serialization.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerialize(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
at WriteExternalReviewMappingItemToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , ClassDataContract )
at System.Runtime.Serialization.ClassDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.InternalSerialize(XmlWriterDelegator xmlWriter, Object obj, Boolean isDeclaredType, Boolean writeXsiType, Int32 declaredTypeID, RuntimeTypeHandle declaredTypeHandle)
at WriteArrayOfExternalReviewMappingItemToXml(XmlWriterDelegator , Object , XmlObjectSerializerWriteContext , CollectionDataContract )
at System.Runtime.Serialization.CollectionDataContract.WriteXmlValue(XmlWriterDelegator xmlWriter, Object obj, XmlObjectSerializerWriteContext context)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.WriteDataContractValue(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.XmlObjectSerializerWriteContext.SerializeWithoutXsiType(DataContract dataContract, XmlWriterDelegator xmlWriter, Object obj, RuntimeTypeHandle declaredTypeHandle)
at System.Runtime.Serialization.DataContractSerializer.InternalWriteObjectContent(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.DataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.DataContractSerializer.WriteObject(XmlWriter writer, Object graph)

This error is mysterious to us, as there's no obvious connection to what we're trying to do.

The error occurred both in versions 18.0.1.2259 and 18.1.2.6370.

Any help would be greatly appreciated.

Best regards,
Bram van der Steen

TerminologyProvider does not reliably generate scores for Fuzzy Search

Lukas Ley — Mon, 01 Sep 2025 09:42:43 GMT

Hello,

I am using Trados Studio 2024 (not SR1) and I have another question.

After getting the search with the TerminologyProviderManager Singleton to work (see the answers in this question) I noticed some strange behavior.
My goal is to get the scores for terms like they are displayed in the "Term Recognition" view in the Editor UI. Ideally I want to put the whole segment string in and get the scores.

When I search via ITerminologyProivder.Search() the scores never line up. Even if I put in only a single term it only lines up when there is a 100% match.

When I put in a longer sentence the score for the best fitting term decreases with the length of the sentence.

For example see this code from the other question:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:ea15cfd2-4189-424b-8b29-84d13a5bc4d9:type=csharp&text=var%20sourceLanguage%20%3D%20new%20CultureInfo%28%22en-US%22%29%3B%0Avar%20targetLanguage%20%3D%20new%20CultureInfo%28%22de-DE%22%29%3B%0Astring%20segmentText%20%3D%20%22...%22%3B%0Aint%20maxResultsCount%20%3D%2010%3B%0Abool%20targetRequired%20%3D%20true%3B%0A%0Avar%20searchResults%20%3D%20terminologyProvider.Search%28%0A%20%20%20%20segmentText%2C%0A%20%20%20%20sourceLanguage%2C%0A%20%20%20%20targetLanguage%2C%0A%20%20%20%20maxResultsCount%2C%0A%20%20%20%20SearchMode.Fuzzy%2C%0A%20%20%20%20targetRequired%0A%29%3B]

If I have a Termbase with the word "Gefahrstoff" in it and when I set the segmentText to "Gefahrstoff" the top searchResult has a score of 100.

If i set the segmentText to "Gefahrstoffen" it has a score of 90. In the Term Recognition view in the Editor UI, "Gefahrstoff" has a Score of 87. The sentence in the Editor is "Die Nutzung von Gefahrstoffen ist gefährlich".
When I set the segmentText to "Die Nutzung von Gefahrstoffen ist gefährlich" the term "Gefahrstoff" has only a score of 63.

Do i really need to parse the thext and search for each token? I would like to avoid doing that. And even if i did that the scores do not line up.

Is there any method for getting the same scores?

Best,
Lukas

RE: TerminologyProvider does not reliably generate scores for Fuzzy Search

Lukas Ley — Mon, 13 Apr 2026 09:45:13 GMT

Hi Patrick Andrew Hartnett ,

I wanted to check in and ask if you can give me any information about further developments on this.

Best, Lukas

MultiTerm COM API Termbases.New() fails when Croatian is present in XDT, but MultiTerm Desktop can create the termbase

Adam Csillag — Fri, 10 Apr 2026 11:16:49 GMT

Hello,

I’m seeing a reproducible issue with MultiTerm COM automation when creating a local termbase from an .xdt definition.

Environment

MultiTerm Desktop 2022 SR2 - 17.2.5.2838
Trados Studio 2022 SR2 - 17.2.12.19268
C# app running as x86 (Environment.Is64BitProcess = False)
Interop: Sdl.MultiTerm.TMO.Interop

Code

Sdl.MultiTerm.TMO.Interop.Application oMt = new Sdl.MultiTerm.TMO.Interop.Application();
TermbaseRepository oLocalRep = oMt.LocalRepository;
oLocalRep.Connect("", "");

Termbases oTbs = oLocalRep.Termbases;
oTbs.New(name, "", definition, sdltbPath);

Example values used

name = "Test"
definition = C:\Users\...\Temp\Test_20260409_141955534\Test.xdt
sdltbPath = C:\Users\...\Temp\Test_20260409_141955534\Test.sdltb

What I tested

The process is 32-bit (Environment.Is64BitProcess = False)
definition exists
sdltbPath does not exist before calling New(...)
Creating in %TEMP% gives the same result as other local paths
Opening an existing .sdltb through COM works:

oLocalRep.Termbases.Add(existingTbPath, "", "");
var tb = oLocalRep.Termbases[existingTbPath];

MultiTerm Desktop can successfully create the termbase from the same .xdt

Observed behavior

Termbases.New(...) throws:
- System.Runtime.InteropServices.COMException: 'MultiTerm is unable to create the termbase.'
After a lot of testing, I found that the problem is related to Croatian in the .xdt
If I remove Croatian from the termbase definition, Termbases.New(...) succeeds
If Croatian is present, Termbases.New(...) fails
However, MultiTerm Desktop is able to create the same termbase from the same .xdt

Question

Is this a known issue in the MultiTerm COM API with Croatian language handling during termbase creation?
Is there a specific Croatian language code/locale that COM expects here?
Could this be related to SH-HR vs hr-HR handling?

Since Desktop can create the termbase, but COM cannot when Croatian is included, this looks like an API-specific issue rather than a broken .xdt.

Thanks in advance for any guidance.

API calls to pretranslate files using DeepL plugin no longer work

TTS Team — Wed, 01 Apr 2026 14:25:52 GMT

Hello,

Since DeepL changed their authentication methods, we no longer can pretranslate our files using API calls to Trados 2024. It still work when pretranslating "manually" from within Trados Studio, but when using the API call

project.RunAutomaticTask(targetFiles.GetIds(), AutomaticTaskTemplateIds.PreTranslateFiles)

, it won't work.

We've narrowed it down to DeepL API key authentication: when adding the DeepL provider manually in Trados Studio, the API key is automatically authenticated when you enter it in the settings dialog for DeepL, but when our external tool uses Trados API to add the DeepL provider to the project using our API key, no such validation occurs, and that's what blocks the pretranslation task from working.

So my question is: is there any way to make it work, it worked just fine before the authentication change? We even tried duplicating the API key authentication when adding the provider to the project, but no luck there.

Thanks for any help on this subject.

RE: API calls to pretranslate files using DeepL plugin no longer work

TTS Team — Thu, 09 Apr 2026 11:09:06 GMT

Thanks again Emanuel Albu , I adapted your code to mine, removing all the complexities we had added to mimic what Trados adds in the provider, and let it do its job, and it worked just fine! That's all there was to it.

RE: API calls to pretranslate files using DeepL plugin no longer work

Patrick Andrew Hartnett — Thu, 09 Apr 2026 09:51:08 GMT

Hey TTS Team , not sure if it helps, but also check and update the App.Config file. we identified some dependencies changed with the latest update a few months ago...
please check here:
RE: Create Project Via API shows files as Reference

RE: API calls to pretranslate files using DeepL plugin no longer work

TTS Team — Thu, 09 Apr 2026 09:46:43 GMT

Hello Emanuel Albu ,

Thanks for the sample code. Ours is very similar (I'm going to try to put it in as much context as possible, while omitting the irrelevant parts).

        public DeepLPluginOptions()
        {
            _uriBuilder = new TranslationProviderUriBuilder("deepltranslationprovider");
        }
        protected TranslationProviderUriBuilder UriBuilderDL => _uriBuilder;

        public void AddDeepLPluginToProject(FileBasedProject project, string apikey, Language locale,
            string settingsName = null, bool cutTag = false)
        {
            var uri = GetUri(apikey, settingsName, cutTag);
            //Console.WriteLine("Saving plugin settings for DeepL/Intento: {0}", uri);
            SaveDeepLPluginSettings(uri, project, locale, apikey);
        }
        
        Uri GetUri(string apikey, string providerId, string providerName, string customAuth = null,
            string customModel = null,
            string glossary = null, string settingsName = null, bool cutTag = false, bool smartRouting = false)
        {
            return UriBuilderDL.Uri;
        }

        public void SaveDeepLPluginSettings(Uri uri, FileBasedProject prj, Language locale, string ApiKey)
        {
            TranslationProviderConfiguration pluginSettings = prj.GetTranslationProviderConfiguration(locale);

            Console.WriteLine("Preparing the JSON string for DeepL MT provider");
            Uri DeepLUri = new Uri("deepltranslationprovider://");
            string state = GetStateObject(uri, prj, locale);
            Console.WriteLine("Creating Trados provider using DeepL settings");
            TranslationProviderReference reference = new TranslationProviderReference(uri, state, true);
            TranslationProviderCascadeEntry entry = new TranslationProviderCascadeEntry(reference, false, true, true, 0);
            pluginSettings.Entries.Add(entry);

            prj = PreTranslationSettings.SetMinimumMatchValue(prj, locale);
            prj.Credentials.AddCredential(DeepLUri, ApiKey);

            prj.UpdateTranslationProviderConfiguration(locale, pluginSettings);
 
            prj.Save();
        }
        
        string GetStateObject(Uri uri, FileBasedProject prj, Language locale)
        {
            System.IO.TextWriter tw = new System.IO.StringWriter();
            JsonTextWriter stateWriter = new JsonTextWriter(tw);
            stateWriter.WriteStartObject();
                stateWriter.WritePropertyName("ApiVersion");
                stateWriter.WriteValue("V2 (DeepL Pro API subscription)");
                stateWriter.WritePropertyName("IgnoreTagsParameter");
                stateWriter.WriteNull();
                stateWriter.WritePropertyName("LanguagePairOptions");
                stateWriter.WriteStartArray();
                    stateWriter.WriteStartObject();
                        stateWriter.WritePropertyName("Formality");
                        stateWriter.WriteValue(0);
                        stateWriter.WritePropertyName("SelectedGlossary");
                        stateWriter.WriteStartObject();
                            stateWriter.WritePropertyName("glossary_id");
                            stateWriter.WriteNull();
                            stateWriter.WritePropertyName("IsChecked");
                            stateWriter.WriteValue(false);
                            stateWriter.WritePropertyName("Name");
                            stateWriter.WriteValue("No glossary");
                            stateWriter.WritePropertyName("source_lang");
                            stateWriter.WriteNull();
                            stateWriter.WritePropertyName("target_lang");
                            stateWriter.WriteNull();
                        stateWriter.WriteEndObject();
                        stateWriter.WritePropertyName("LanguagePair");
                        stateWriter.WriteStartObject();
                            stateWriter.WritePropertyName("SourceCultureName");
                            Sdl.ProjectAutomation.Core.ProjectInfo prjSettings = prj.GetProjectInfo();
                            string SrcLang = prjSettings.SourceLanguage.CultureInfo.Name;
                            string TgtLang = locale.CultureInfo.Name;
                            stateWriter.WriteValue(SrcLang);
                            stateWriter.WritePropertyName("TargetCultureName");
                            stateWriter.WriteValue(TgtLang);
                        stateWriter.WriteEndObject();
                    stateWriter.WriteEndObject();
                stateWriter.WriteEndArray();
                stateWriter.WritePropertyName("LanguagesSupported");
                stateWriter.WriteStartObject();
                    stateWriter.WritePropertyName(TgtLang);
                    stateWriter.WriteValue("DeepLTranslator");
                stateWriter.WriteEndObject();
                stateWriter.WritePropertyName("PreserveFormattingParameter");
                stateWriter.WriteValue(false);
                stateWriter.WritePropertyName("SendPlainTextParameter");
                stateWriter.WriteValue(false);
                stateWriter.WritePropertyName("ResendDraftParameter");
                stateWriter.WriteValue(false);
                stateWriter.WritePropertyName("ModelTypeParameter");
                stateWriter.WriteValue("Latency_Optimized");
                stateWriter.WritePropertyName("TagHandlingParameter");
                stateWriter.WriteValue("None");
                stateWriter.WritePropertyName("SplitSentenceHandlingParameter");
                stateWriter.WriteValue("Default");
                stateWriter.WritePropertyName("Uri");
                stateWriter.WriteValue("deepltranslationprovider:///");
            stateWriter.WriteEndObject();

            return tw.ToString();
        }

        static int Main(string[] args)
        {

            MtTask mtTask = new MtTask(args[0]);

            try
            {
                ProjectProcessor processor = new ProjectProcessor();

                FileBasedProject project = processor.SetProject(mtTask.ProjectFile);

                foreach (TargLang targLang in mtTask.TargLangs)
                {
                    if (targLang.Provider == "DeepL")
                    {
                        Console.WriteLine($"Configuring DeepL Settings for {targLang.Lang.ToString()}...");
                        DeepLPluginOptions options = new DeepLPluginOptions();
                        options.AddDeepLPluginToProject(
                            project,
                            targLang.Api,
                            targLang.ProviderId,
                            targLang.ProviderName,
                            targLang.Lang
                        Console.WriteLine($"Pre-translating {targLang.Lang} files...");

                        processor.PreTranslateTargetLanguageFiles(project, targLang.Lang);
                    }
                }

                return ConsoleHelper.WriteSuccess("PackageCreation");
            }
            catch (Exception ex)
            {
                return ConsoleHelper.WriteError(ex);
            }
        }

As you can see, for the most part, it goes more or less the same way, except we spell out the json content to be inserted as the provider State. Or do we have to rely completely on Trados to insert it automatically? We tried it that way, and it didn't seem to work...

RE: Create Project Via API shows files as Reference

Patrick Andrew Hartnett — Thu, 09 Apr 2026 09:24:51 GMT

Hi Mark Owens ,

Thanks for reporting this and for the sample materials.

We’ve identified the issue. It appears to be related to a dependency change in latest release of Studio 2024, which means your project needs a few additional binding redirects in the App.config file.

I’ll update our public documentation in the next few days, but in the meantime, please try using the attached/full App.config as a reference:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
  </configSections>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8" />
  </startup>

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Memory"
                                publicKeyToken="cc7b13ffcd2ddd51"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.1.2"
                               newVersion="4.0.1.2" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe"
                                publicKeyToken="b03f5f7f11d50a3a"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
                               newVersion="6.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Logging"
                                publicKeyToken="adb9793829ddae60"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
                               newVersion="8.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions"
                                publicKeyToken="adb9793829ddae60"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
                               newVersion="8.0.0.2" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Options"
                                publicKeyToken="adb9793829ddae60"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
                               newVersion="8.0.0.2" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable"
                                publicKeyToken="b03f5f7f11d50a3a"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
                               newVersion="8.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Text.Encoding.CodePages"
                                publicKeyToken="b03f5f7f11d50a3a"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535"
                               newVersion="8.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Tasks.Extensions"
                                publicKeyToken="cc7b13ffcd2ddd51"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.1"
                               newVersion="4.2.0.1" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Text.Json"
                                publicKeyToken="cc7b13ffcd2ddd51"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.6"
                               newVersion="8.0.0.6" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces"
                                publicKeyToken="cc7b13ffcd2ddd51"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.0"
                               newVersion="8.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Diagnostics.DiagnosticSource"
                                publicKeyToken="cc7b13ffcd2ddd51"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.1"
                               newVersion="8.0.0.1" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.DependencyInjection.Abstractions"
                                publicKeyToken="adb9793829ddae60"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.2"
                               newVersion="8.0.0.2" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.DependencyInjection"
                                publicKeyToken="adb9793829ddae60"
                                culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.0"
                               newVersion="8.0.0.1" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

  <log4net>
    <!-- Set levels to DEBUG for extended logging information -->
    <appender name="RollingFile" type="Sdl.Desktop.Logger.LocalUserAppDataFileAppender, Sdl.Desktop.Logger">
    </appender>
    <!-- output to debug string -->
    <appender name="OutputDebug" type="log4net.Appender.OutputDebugStringAppender">
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />
      </layout>
    </appender>
    <root>
      <level value="INFO" />
      <appender-ref ref="RollingFile" />
      <appender-ref ref="OutputDebug" />
    </root>
    <logger name="Sdl.TranslationStudio">
      <level value="INFO" />
    </logger>
    <logger name="Sdl.Desktop">
      <level value="INFO" />
    </logger>
    <logger name="Sdl.ProjectApi">
      <level value="INFO" />
    </logger>
    <logger name="Licensing">
      <level value="INFO" />
    </logger>
    <!--<logger name="Sdl.MultiTerm">
      <level value="DEBUG"/>
    </logger>-->
  </log4net>
</configuration>

thx Crina Salagean for helping to pinpoint this.

Please let me know whether this resolves the issue on your side.

Create Project Via API shows files as Reference

Mark Owens — Mon, 30 Mar 2026 11:05:15 GMT

I've recently upgraded to Trados 2024, and am running code that creates a new project from a Studio 2024 template, add files, and machine translates. All VS references are for Studio 2024 assemblies.

The template is setup exactly as you'd expect to do this. There is no memory selected, and the DeepL translation configuration is correct. The file types for the template have most entries in the list unticked, but XML2: MadCap Compliant is ticked.

The program steps are:

Create project
AddFolderWithFiles (recursively)
Save project
Scan files
Save project
ConvertToTranslatableFormat (via RunAutomatiobTask)
CopyToTargetLanguages (via RunAutomatiobTask)
Save project
Modify settings to applyAutomatedTranslation
Save settings
Save project
PreTranslateFiles (via RunAutomatiobTask)
Save project

It never seems to use the project template setting to recognise the .htm files are translatable.

If I create the project manually, with the same template, same source files, it performs the MT as expected.

There must be some sort of gotcha going on. Can anyone tell me where I'm going wrong?
Thanks

Mark

RE: API calls to pretranslate files using DeepL plugin no longer work

Emanuel Albu — Wed, 08 Apr 2026 12:15:12 GMT

Hello TTS Team !

How are you trying to use the DeepL provider?

I just tested the 7.1.5.0 version and it worked. The code I used is this:

using System;
using Sdl.Core.Globalization;
using Sdl.ProjectAutomation.Core;
using Sdl.ProjectAutomation.FileBased;
using Sdl.ProjectAutomation.Settings;

namespace StandAloneConsoleApp_PretranslateUsingProvider
{
    public class Program
    {
        private static string GetDateTimeToString(DateTime dateTime)
        {
            var value = dateTime.Year +
                        dateTime.Month.ToString().PadLeft(2, '0') +
                        dateTime.Day.ToString().PadLeft(2, '0') +
                        "-" +
                        dateTime.Hour.ToString().PadLeft(2, '0') +
                        dateTime.Minute.ToString().PadLeft(2, '0') +
                        dateTime.Second.ToString().PadLeft(2, '0');
            return value;
        }

        private static void Main(string[] args)
        {
            var projectInfo = new ProjectInfo
            {
                Name = "",
                SourceLanguage = new Language(""),
                TargetLanguages = new[] { new Language("") },
                LocalProjectFolder = $@"PathWhereProjectsWillBeSaved\{GetDateTimeToString(DateTime.Now)}"
            };

            var project = new FileBasedProject(projectInfo);

            UpdateProjectProviderSettings(project);

            var tpConfig = project.GetTranslationProviderConfiguration();

            var tpUriString = "deepltranslationprovider:///";
            var tpReference = new TranslationProviderReference(new Uri(tpUriString), null, true);
            var tpCascadeEntry = new TranslationProviderCascadeEntry(tpReference, true, true, false);
            tpConfig.Entries.Add(tpCascadeEntry);
            project.UpdateTranslationProviderConfiguration(tpConfig);

            var apiKey = "";
            project.Credentials.AddCredential(new Uri(tpUriString), apiKey);
            project.Save();

            var projFiles =
                project.AddFiles(
                    new[] { @"filepaths" });

	        //var projFiles = project.AddFolderWithFiles(@"", true);

            project.RunAutomaticTasks(projFiles.GetIds(), new[]
            {
                AutomaticTaskTemplateIds.Scan,
                AutomaticTaskTemplateIds.ConvertToTranslatableFormat,
                AutomaticTaskTemplateIds.CopyToTargetLanguages,
                AutomaticTaskTemplateIds.PreTranslateFiles,
            });

            project.Save();
        }

        private static void UpdateProjectProviderSettings(FileBasedProject project)
        {
            var settings = project.GetSettings();
            var preTranslateSettings = settings.GetSettingsGroup<TranslateTaskSettings>();
            preTranslateSettings.NoTranslationMemoryMatchFoundAction.Value = NoTranslationMemoryMatchFoundAction.ApplyAutomatedTranslation;
            preTranslateSettings.MinimumMatchScore.Value = 75;

            project.UpdateSettings(settings);
            project.Save();
        }
    }
}

RE: API calls to pretranslate files using DeepL plugin no longer work

TTS Team — Tue, 07 Apr 2026 13:08:48 GMT

Any news?

RE: API calls to pretranslate files using DeepL plugin no longer work

TTS Team — Thu, 02 Apr 2026 09:38:08 GMT

We use the latest published version, 7.1.5.0

RE: API calls to pretranslate files using DeepL plugin no longer work

Patrick Andrew Hartnett — Thu, 02 Apr 2026 07:29:17 GMT

hey TTS Team , what is the version of the plugin that is installed on the machine where you are running the automation?

RE: Create Project Via API shows files as Reference

Patrick Andrew Hartnett — Wed, 01 Apr 2026 15:20:21 GMT

hey Mark Owens , I’ve investigated this issue and have been able to reproduce it.

The problem appears to start during the Automatic Task Scan step. At that stage, the SourceFile role should normally be identified as Translatable, Reference, or Unknown. However, in my testing, the files are consistently being set to Unknown or Reference, even for file types that would normally be expected to be translatable (for example, a simple .htm file).

Because the scan is not classifying the files correctly, the bilingual files are not generated, and as a result the downstream project automation steps do not proceed as expected.

At this point, this appears to be a product issue rather than expected behavior. I have escalated it to the Studio team for review. I do not have an ETA yet, but I will update this thread once I have more information.

Thanks for reporting it and for providing the sample materials, which helped confirm the behavior.

Internal Reference: SRQ-30939

RE: Create Project Via API shows files as Reference

Mark Owens — Wed, 01 Apr 2026 11:10:57 GMT

Thanks Patrick, You should receive an email with links to the relevant files

RE: Create Project Via API shows files as Reference

Patrick Andrew Hartnett — Wed, 01 Apr 2026 10:32:18 GMT

Hi Mark Owens , can you share the code project (and possibly the project template) so that we can understand better what the problem might be.

pls send to phartnett@rws.com

Don't send the zip in the e-mail, instead upload it to Dropbox, onedrive or other and share the download link with me via e-mail. then I'll take a look and provide some feedback.

RE: Request for meeting to clarify TM matching behavior with Lara integration

Patrick Andrew Hartnett — Tue, 10 Mar 2026 08:13:24 GMT

Hi Giulia Ceccacci , maybe a better start would be to provide a sample project and steps + expectations, so that we can reproduce the exact scenario you are describing above? We can then better determine if what you are describing is expected behavior or not and take it from there. WDYT?

Request for meeting to clarify TM matching behavior with Lara integration

Giulia Ceccacci — Thu, 05 Mar 2026 09:18:45 GMT

My name is Giulia Ceccacci and I work at Translated, where I focus on technical support for Lara, our AI translation platform.

I've recently been running several tests on the integration between Lara and Trados Studio, and I’ve noticed a few behaviors regarding translation memory matching and segment confirmation that I would like to better understand from your side.

In particular, I’m seeing some inconsistencies in how TM matches (including 90% matches) are recognized by Trados depending on whether the TM is selected in Trados, in Lara, or in both. In some cases Lara correctly retrieves a match from the TM, but Trados does not recognize it as a TM match, which means the segment still needs to be manually confirmed.

Additionally, I’m observing a bug where the suggested translation reverts to the source language when the segment is confirmed, which we are currently investigating on our side.

Since some of these behaviors may depend on how Trados handles TM matches, pre-translation settings (e.g. Keep Existing Translations), and external providers, I think it would be very helpful to schedule a short meeting to walk through the scenarios together and clarify what we should expect from the Trados side.

Would you be available for a quick call in the coming days?

Let me know,

Giulia

TradosAPI within Plunet Ran out of Memory message

David McDermit — Tue, 03 Mar 2026 14:54:35 GMT

Hello

Have been having an issue with the TradosAPI within Plunet to run analysis of translation requests.

Presently have updated the server and all programs within Plunet and the TradosAPI. This seems to have fixed the Critical error message we would get when running jobs over 1100 words. After getting everything up-to-date we are now running into a Ran out of Memory message when running larger jobs.

What can I supply that might help solve this issue?

RE: TradosAPI within Plunet Ran out of Memory message

Daniel Brockmann — Wed, 04 Mar 2026 13:56:59 GMT

Yes - we have enhanced memory handling over the years so the situation got better, but we were still hitting a hard limit with 32-bit with approx. 3 GB max. Now with 64-bit, that limit goes away and we should not run into such OOM errors anymore on current hardware. So it might be good to validate that when you can with the beta version.